What is your primary use case for ELK Elasticsearch?

I can describe a project where we use Elasticsearch, Logstash, and Kibana (ELK stack) for our archiving objectives. I work in the security department of a Fintech company in the payment industry. We use the ELK stack to connect our internal systems with the bank's systems and we used Beats for data collection. We then store and forward this data to Elasticsearch for indexing and analysis, visualize and create alerts using Kibana based on categorized access logs, identifying and blocking malicious traffic or payloads.

We use the product for log analytics and metrics features.

We use the product for log management.

We save credentials, new account information, logs from Palantir Panorama, Firefox logs, traffic logs, GlobalProtect logs from our servers, and Active Directory new users. We're still improving this, but not very fast.

We use the solution for search engines and indexing.

We use the solution to monitor website request responses. We also used it for APM and searching for slow and database queries.

We use the solution for log gathering, analyzing, and dashboard creation (with Kibana). For example, several clients require the ability to store and search logs freely without the constrictions that would be in place if a traditional database was used. Elasticsearch is perfect for these use cases since it is a non-SQL database with advanced querying capabilities based on the Lucene search engine. There is excellent support and a large community that answers possible questions online in detail and very quickly. I was amazed at the help I got several times.

We are using the solution for our products. We are keeping some DBs where we are doing pattern searches. On the application side, we are keeping those in Elastic and a huge amount of data for our different product lines.

We use the solution mainly for logs today. There are other teams that use it for other use cases. We just use it for logging and logging search and these kinds of things.

It's a cloud-based service. At that time, we were using AWS, so we could get the same Elasticsearch capabilities from AWS. It was mostly a PaaS service that we could access. We had the Elasticsearch specific server and database hosted on an AWS instance, and then we fed the data to it and tried to fine-tune the algorithm to give the necessary search intelligence that we needed. We're not using the latest version. We're using a version that was released one year ago. The whole organization has about half a million users, but at any point of time, a hundred users might be using it.

Our company uses the solution for centralized logging and monitoring. We have slowly moved our Stackdriver to the solution as a cost-cutting measure. We have more than 100 technicians using the solution.

Elastic Enterprise Search is the repository for time series and data from the onsite instrument that monitors variables in our mining infrastructure called tailing dams. We monitor the tailing dams' physical stability and take the information from the sales force and manual data introduced by the operators. The system captures the information in the Elastic Enterprise Searchtime series, and we make calculations and trigger events and alerts based on those calculations. We save them as well as the events and alert times.

All my use cases have been based more on observability for IT operations. We deal with it in terms of metrics, logs, transactions, traces, and so on. In terms of enterprise, most of the use cases are based on search capacity within the company to find documents and relevant information. That is the main use case.

We are using Elastic Enterprise Search for monitoring and alerting. It will look for any kind of possible error that is on the infrastructure side and give notifications.

I am using Elastic Enterprise Search for the visualization of logs.

Elastic Search is added advantage for us because we normally use it for our uptime monitoring and our log analysis. When we merge it with Splunk, it helps us correlate and do security monitoring. Elastic Enterprise Search comes embedded within a solution that we have developed for our clients. It's a payment solution. We've recently shipped it with Elastic Enterprise Search embedded. All the logs and all the internal communications get captured by Elastic Enterprise Search. It makes it easy for the IT teams who are doing uptime monitoring and troubleshooting to have a look at it. We have the security teams develop their own monitoring metrics and logs, if they wish, based on their deployment. The beauty of Elastic Enterprise Search is if they also have their own third-party tools, there's the ability to integrate and read off Elastic Enterprise Search and have any third-party tool process the logs as well. It is highly extensible.

We are mainly using it for analytics reports for the data taken from our call center. We are using the entire stack. We are using Kibana and Elasticsearch. Kibana is the front end for dashboards, reports, etc.

We are internal integrators. We are in the bigger group as of now, but other groups, our clients, are affiliates from our group. They are our internal clients. The solution is currently on-premises. I was mostly responsible for the SOC team, and I helped them create the detection rules for the production. I wanted to know how it could be implemented in different kinds of products, like Sentinel.

We use ELK Elasticsearch for storing application data logs.

Our main use case is to centralize all the logs from the infrastructure environment and the data center.

Elasticsearch is one of the NoSQL databases available. My application is a microservices application where the data gets published on a Kafka cube. It allows us to connect to Kafka and get this data in a document format very easily. I'm using Elasticsearch as my backend processing database, where I'm building and reporting using Kibana.

We are primarily using it for monitoring. It is used for server monitoring.

We are developing a SIEM application that is similar to QRadar, ArcSight, or Splunk. This application uses Elasticsearch as its search engine because we want to retrieve information fast. We are just using the basic search engine part of Elasticsearch. We have developed lots of things on top of Elasticsearch, such as security, correlation, reporting, etc.

I am using it to get some hands-on experience and learn the product by searching, building use cases, test cases, dashboards, and visualizations. With hands-on experience, you learn more about the product and how it works.

I am using this product for a SIM solution.

Our primary use case of this solution is for monitoring our logs and infrastructure. We are customers of ELK and I'm a system administrator.

I'm involved in architecting and implementing Elasticsearch-based solutions, catering to various use cases including IIoT, cybersecurity, IT Ops, and general logging and monitoring. The intention of this article is not to compare AWS Elasticsearch with Elastic ELK Elasticsearch and at the end declare the winner. Elasticsearch by itself is one of the coolest and versatile Big Data stacks out there. If you are planning to use it in your organization or trying to evaluate if it is the right stack for your product/ solution, this article offers some insights from an architect's perspective.

I run the function to review the usage for the team and for the organization itself. We use this product internally and then some of our business relationships with the other businesses that we have, they get their data from our data. It's more for collaborative data reporting that we have with them.

My organization works in the healthcare industry and we use this product as our database. When we have questions about our data then we use Elasticsearch to make queries.

The primary use case of this solution is for text indexing and aggregating logs from different microservices.

We try to detect malicious files by the logs. The logs are all centralized including all our PCs, our callers, our servers, Linux, windows, Polaris names. We scan everything. Then we have pre-defined specific use cases that allow us to identify if there is an attack on the machine or indirectly by the endpoint. On top of that, we can check with users as we're not directly dealing with the configuration, so we can follow up on the alerts we receive. On top of that, we have the systems in place that allow us to detect if certain inexcusable items are on the system, such as malicious files. We can do this because we also retrieve the log files of the identifiers.

In terms of use case, we combine a lot of things with Elastic. It's two platforms, so with Elasticsearch, we're using the Beats, Kibana, and Suricata. It's a query engine and we use the information from our sensors. It gets ingested into that and we use the resources to get everything put on our dashboards. If something is detected, alerts come up right away and it's very, very accurate. The more ingest it receives, the better we can respond to threats. It's not just Elastic or Logstash, it's a combination of those and other tools that we would apply towards our threat detection and prevention. We have a partnership with ELK.

What we use this ELK (Elasticsearch, Logstash, and Kibana) solution is mostly for keeping firewall logs and collecting traffic flow information.

I'm a data scientist and we're a customer of ELK. We use the solution for multiple projects, mainly based around customer analytics.

I use Elasticsearch with Logstash and Kibana.

We use this solution to collect log data and analyze it. We have an on-premises deployment.

Our primary use case for this solution is to operate an integration platform for a warehouse management system.

In my project, Elasticsearch is used to query terms for search and to provide data boards for our project team.