ElixirConf 2016 - Measuring your elixir App

4569aec00cb223b3fbf484f9e7ba1256?s=47 Renan Ranelli
September 06, 2016

ElixirConf 2016 - Measuring your elixir App

4569aec00cb223b3fbf484f9e7ba1256?s=128

Renan Ranelli

September 06, 2016
Tweet

Transcript

  1. 4.
  2. 5.
  3. 8.

    Why should I care? We write code. We do it

    because it generate business value.
  4. 9.

    Why should I care? We write code. We do it

    because it generate business value. But this business value is generated only when our code *runs*. *NOT* when it is written
  5. 10.

    Why should I care? In order to make good decisions

    about something, we must understand it.
  6. 11.

    Why should I care? In order to make good decisions

    about something, we must understand it. (And we want to make good decisions because we like getting paid)
  7. 29.

    Metrics – average value First thing you should ask: Which

    time period does this average refer to ??? Averages completely destroy the **variability** and **recency**.
  8. 30.

    Metrics – average value A common thing to do is

    add a “decay” component to the average calculation:
  9. 31.

    Metrics – average value A common thing to do is

    add a “decay” component to the average calculation:
  10. 34.

    Histograms Histograms are like averages on steroids. As such, you

    **have** to pay attention to The aggregation period it refers to
  11. 38.

    You have to solve these parts: ❑ Collect ❑ Store

    ❑ Query, Analyze & Transform ❑ Visualize ❑ … ❑ MAKE DECISIONS (!)
  12. 39.

    Our metrics collection architecture Log parsing Exometer & Elixometer Influxdb

    plugin “report api” Query & Visualize Transform & Analyze STORE Collect Store View
  13. 40.

    Our (boring) choices ❑ Collect •Exometer & Elixometer are very

    easy to set up •We have used collectd extensively in the past ❑ Store (InfluxDB) •**Very** easy to set up & configure. And free. •Built-in retention policy configuration •Awesome query language & Continuous queries •Plugs seamlessly with grafana
  14. 41.

    Our (boring) choices ❑ View (Grafana) •We have used it

    in the past. •It is awesome and beautiful (you will see!)
  15. 42.

    Our (boring) choices ❑ You might ask: ❑ Why you’re

    not using solution like Splunk, DataDog, etc?
  16. 43.

    Our (boring) choices ❑ You might ask: Why you’re not

    using solution like Splunk, DataDog, etc? ❑ Our answer: ❑ We don't like our data outside our walls. Also, NDAs and legal obligations
  17. 44.

    Exometer & Elixometer ❑ Exometer Exometer Reporter Metrics buffer (pre

    aggregated ) High frequency Metric reports Store & update Aggregated view Collect & convert Low frequency Metrics formated for other backends
  18. 45.

    Exometer & Elixometer ❑ This design is almost omnipresent in

    metrics world. ❑ Other tools like statsd, telegraf, etc might fit the role of exometer in your case. Use the one you’re most comfortable with. ❑ It is **very** important to be able to control the frequency which your storage receives requests. You don’t want to overload it.
  19. 46.

    DEMONSTRATION • Measuring all requests to a phoenix app Step

    by step instructions here: http://milhouseonsoftware.com/2016/05/08/me asuring-your-elixir-application/
  20. 48.

    Other things you should measure ❑ The Erlang VM is

    **awesome** (and that’s why we’re here ;P) ❑ There are lots of resources out there on how to measure, monitor and operate it. ❑ But sadly I don’t have enough time to go in depth about it ~ Use vm_stats to gather virtual machine metrics! https://github.com/ferd/vmstats
  21. 49.

    Other things you should measure ❑ The Erlang VM is

    **awesome** (and that’s why we’re here ;P) ❑ ❑ There are lots of resources out there on how to measure, monitor and operate it. ❑ ❑ But sadly I don’t have enough time to go in depth about the things the instrumentation the VM exposes ~
  22. 50.

    Other things you should measure ❑ The Erlang VM is

    **awesome** (and that’s why we’re here ;P) ❑ ❑ There are lots of resources out there on how to measure, monitor and operate it.
  23. 52.

    Closing remarks ❑ Find “seams” in your code where you

    can “plug” measurements. ❑ Try not to spread metrics reporting “everywhere”. It’s best to separat “high level” measurements from “low level” ones. ❑ This is just the beginning. After you have this infrastructure in place, you have to start doing analysis, correlation and other math stuffs. That’s where the real *gold* is.
  24. 53.

    Closing remarks ❑ Bend your metrics to generate alerts. This

    is **really** awesome. ❑ Another (similar) metrics collection architecture is described here: http://tech.footballaddicts.com/blog/gathering-metrics-in-elixir- applications ❑ Zed Shaw has an awesome post about statistics: ❑https://zedshaw.com/archive/programmers-need-to-learn-statistics- or-i-will-kill-them-all/
  25. 54.