4 ms·

What's worse (and I've seen this trend a lot) is to use Elasticsearch for metrics. My god.

• detaro 5y ago
  > (and I've seen this trend a lot) any idea why? Seems like an odd approach to me.
  • denysvitali 5y ago
    Because people like to have everything (logs + metrics) in the same place. And probably Beats makes it easier to just ship everything in Elasticsearch (but of course this doesn't make it good)
  • atombender 5y ago
    Because that's what Elastic is positioning Elasticsearch for. If you look at the features being added these last few years, so much is about time series stuff — aggregation, time-based partitioning, warm/cold storage, etc. Relatively little focus on structured search.
  • moduspol 5y ago
    I was interviewing earlier this year and saw at least three companies actively planning to migrate from their existing relational databases into Elasticsearch. It seems to commonly be perceived as a panacea of databases.
    • alkz 5y ago
      in most cases elastic is easier to scale than a relational or timeseries db
      • moduspol 5y ago
        I mean, kind of? It depends on what your data looks like and how you're querying it. If you're not doing free-text search, and your data will fit in memory in a big relational database VM for the foreseeable future, why Elasticsearch?
        • alkz 5y ago
          sure relational db is ok if fits in memory, but if we're talking about TBs of metrics i'd rather look for another way
  • closeparen 5y ago
    When I see a nonzero value in a metric about “things that shouldn’t happen,” the very next thing I’m going to ask for is examples. It’s generally considered too expensive to derive metrics from logs in this way, but it’d be a killer debugging experience.
• beardface 5y ago
  Why do you consider this a bad thing?
  • 101011 5y ago
    I'm not convinced it is a bad thing. Good scale, relatively low latency, keeps your infrastructure costs down, and many of the other alerting options (looking at you Datadog and NewRelic) are crazy expensive. Open to hearing other opinions though.
  • denysvitali 5y ago
    Because you're suddenly putting metrics (that should belong to a time-series database) into a full-text search database. The result is a dashboard that takes ages to load just to show a trend in values. I think it's using the wrong tool for the job, but maybe it's just me.
    • nemo44x 5y ago
      I think you may want to check your mappings/templates. There are a lot of data types for this kind of data and they don't rely on the inverted index that you would use for searching fields. Lucene, which Elasticsearch is built on, has a feature called "doc values" that stores data as column-oriented fields. This makes for the fast aggregations, sorting, and grouping for numeric and text fields. One of the main strengths of Elasticsearch is that you can use it for searching and aggregating in a single query. But you need to ensure you are searching on fields that are indexed for search and sorting/aggregating on fields that are indexed for that.
    • beardface 5y ago
      Elasticsearch is fine for time series data. A lot of tasks are actually easier with time series data. You add a field called `@timestamp` to your documents and a lot of analysis becomes possible, like date histograms, date range queries, ML jobs, etc. Immutable time series data like logs and metrics are a great fit for Elasticsearch due to the way Lucene stores data. Documents in Lucene are immutable so an update in Elasticsearch is creates a new document and places a tombstone marker on the old one. Immutable data means you don't have to tolerate those inefficiencies. Dashboards don't load the entire dataset by default. I can't remember what the exact default time range is but I think it's ~15 minutes or so. They're fairly quick to render in Kibana. Elasticsearch is a great tool for observability data (logs, metrics, and APM data). Elastic's tooling makes a lot of this really easy in most cases.
• tunesmith 5y ago
  I'm struggling with this currently. I want to record some metrics with our codebase, like counting each time a certain thing happens. Our code logs requests and response times to ElasticSearch, so there's the option of just "logging" these metrics so ElasticSearch has them too. It just seems a mismatch to me. Earlier I wanted to create a dashboard that graphed some derived stats off of that request data, like server utilization which depends on doing some math with average request count and average response time - it just didn't seem like elastic search dashboards easily supported that. I was able to do it on the AWS lb level with Cloudwatch. Not having had exhaustive training with ElasticSearch maybe I'm looking for a separate metrics system like statsd and Grafana.
• CSDude 5y ago
  Elasticsearch, with a mapping that does not full text search indices disabled, and a relatively larger time, works very well for timeseries data. It does filtering & metric and bucket aggregations crazy fast. And it's very easy to add a new node. Just run on spot instances. We push event per request, which might have 100-500 unique keys, 100 millions of records per day, and no solution we've tried comes at the easiness of Elastic. Try to replicate the freedom (no-schema, cardinality, adding a new node to cluster) of Elasticsearch with InfluxDB or others and you will hit cardinality problems real fast.
• stackedinserter 5y ago
  It's fine for metrics, we've been using it for few years.