Need For Search

Need For Search

We are all accustomed to search. We search to find answers. In the log analytics world, those answers have improved customer retention, aided better decisions. But the search is a tedious process.

Well, what if we don’t have to search, what if the information has arranged in such a way that we can discover it. Remember the old search engines like excite where they divide the web into directories, everything arranged in a hierarchy. What if we could similarly discover our logs.

In our infrastructure, there could be thousands of containers running. If we have to root cause an issue specific to a container, the usual way to do this is to go to a logs search page, apply filters to drill down to the specific container we have to look into. The filters depend on how we have segregated the logs from our infrastructure. We need to apply multiple filters like the namespace, StatefulSet or pod identifiers etc..

Now let’s think for a moment. This need not be a haystack. In the case of Kubernetes based deployments, a hierarchy exists. Each Kubernetes cluster has namespaces. Namespace has multiple Kubernetes entities like StatefulSets or Deployments. Each of these has one or more pods.

kubernetes entity hierarchy

Ultimately what we need is the logs from these individual containers. Instead of search what if we could just discover it the way you could discover files from directories.

Related articles

Observability Best Practices

The term “observability” has gone viral in the cloud industry, at least among IT professionals.

Gathering logs from Google Autopilot

In any modern containerized workload setting, container orchestration is imperative. Purportedly, the majority of contemporary

The LOGIQ blog

Let’s keep this a friendly and inclusive space: A few ground rules: be respectful, stay on topic, and no spam, please.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More insights. More affordable.
Less hassle.