<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/"/>
	<rdf:li rdf:resource="https://github.com/remuslazar/homeassistant-carwings"/>
	<rdf:li rdf:resource="https://github.com/louislam/uptime-kuma"/>
	<rdf:li rdf:resource="https://berthub.eu/articles/posts/client-side-scanning-dutch-parliament/"/>
	<rdf:li rdf:resource="https://www.esbnetworks.ie/existing-connections/meters-and-readings/my-smart-data"/>
	<rdf:li rdf:resource="https://hveem.no/visualizing-latency-variance-with-grafana"/>
	<rdf:li rdf:resource="https://brunty.me/post/energy-monitoring-2022-edition/"/>
	<rdf:li rdf:resource="https://pyroscope.io/"/>
	<rdf:li rdf:resource="https://www.browse.ai/"/>
	<rdf:li rdf:resource="https://www.sciencedirect.com/science/article/pii/S0048969722029254"/>
	<rdf:li rdf:resource="https://nelsonslog.wordpress.com/2022/01/20/my-custom-solar-monitoring-system-pvs6/"/>
	<rdf:li rdf:resource="https://visualping.io/"/>
	<rdf:li rdf:resource="https://github.com/hubblo-org/scaphandre/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/"/>
	<rdf:li rdf:resource="https://www.hpsc.ie/a-z/respiratory/influenza/seasonalinfluenza/surveillance/influenzasurveillancereports/20192020season/"/>
	<rdf:li rdf:resource="https://square.github.io/cubism/"/>
	<rdf:li rdf:resource="https://arxiv.org/pdf/2001.06561.pdf"/>
	<rdf:li rdf:resource="https://sysdig.com/blog/golden-signals-kubernetes/"/>
	<rdf:li rdf:resource="https://www.theguardian.com/info/developer-blog/2016/dec/05/testing-in-production-how-we-combined-tests-with-monitoring"/>
	<rdf:li rdf:resource="https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring/"/>
	<rdf:li rdf:resource="http://www.livpi.com/store/c1/Featured_Products.html"/>
	<rdf:li rdf:resource="https://improbable.io/games/blog/thanos-prometheus-at-scale"/>
	<rdf:li rdf:resource="https://www.datadoghq.com/blog/rabbitmq-monitoring/"/>
	<rdf:li rdf:resource="https://opensource.googleblog.com/2018/01/opencensus.html"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/diabetes/comments/7nvufy/my_bedroom_lights_turn_on_when_my_blood_sugar/"/>
	<rdf:li rdf:resource="https://sourcegraph.github.io/checkup/"/>
	<rdf:li rdf:resource="https://blog.hostedgraphite.com/2017/07/06/continuous-self-testing-at-hosted-graphite-why-we-send-external-canaries-every-second/"/>
	<rdf:li rdf:resource="https://drive.google.com/file/d/0BzRE_fwreoDQNzUybnRFOHpWZTA/view"/>
	<rdf:li rdf:resource="http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html"/>
	<rdf:li rdf:resource="https://bcicen.github.io/ctop/"/>
	<rdf:li rdf:resource="https://code.facebook.com/posts/952820474848503/beringei-a-high-performance-time-series-storage-engine/"/>
	<rdf:li rdf:resource="http://ispokemongodownornot.com/"/>
	<rdf:li rdf:resource="https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit"/>
	<rdf:li rdf:resource="https://blog.raintank.io/dear-graphite-users-and-developers/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/apn/key-metrics-for-amazon-aurora/?adbsc=APN_Blog_20160512_61520166&amp;adbid=730767018157170688&amp;adbpl=tw&amp;adbpr=509089629"/>
	<rdf:li rdf:resource="https://coreos.com/blog/coreos-and-prometheus-improve-cluster-monitoring.html"/>
	<rdf:li rdf:resource="https://github.com/firehol/netdata"/>
	<rdf:li rdf:resource="https://blog.twitter.com/2016/observability-at-twitter-technical-overview-part-ii"/>
	<rdf:li rdf:resource="http://prometheus.io/blog/2016/03/23/interview-with-life360/"/>
	<rdf:li rdf:resource="https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/"/>
	<rdf:li rdf:resource="https://www.vividcortex.com/blog/why-percentiles-dont-work-the-way-you-think"/>
	<rdf:li rdf:resource="https://en.wikipedia.org/wiki/Floating_car_data"/>
	<rdf:li rdf:resource="https://www.vividcortex.com/blog/2015/11/05/nobody-loves-graphite-anymore/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/message/5467D2/"/>
	<rdf:li rdf:resource="http://www.eightypercent.net/post/layers-in-the-stack.html"/>
	<rdf:li rdf:resource="https://blogs.aws.amazon.com/bigdata/post/Tx3ET30EGDKUUI2/Implementing-Efficient-and-Reliable-Producers-with-the-Amazon-Kinesis-Producer-L"/>
	<rdf:li rdf:resource="https://engineering.linkedin.com/sre/introducing-nurse-auto-remediation-linkedin"/>
	<rdf:li rdf:resource="https://www.datadoghq.com/blog/how-to-monitor-nginx/"/>
	<rdf:li rdf:resource="https://github.com/aragozin/jvm-tools"/>
	<rdf:li rdf:resource="http://githubengineering.com/brubeck/"/>
	<rdf:li rdf:resource="https://gist.github.com/acolyer/95ef23802803cb8b4eb5"/>
	<rdf:li rdf:resource="http://techblog.netflix.com/2015/04/introducing-vector-netflixs-on-host.html"/>
	<rdf:li rdf:resource="http://www.slideshare.net/jallspaw/etsy-codeascraft-allspaw1"/>
	<rdf:li rdf:resource="http://hekad.readthedocs.org/en/v0.9.0/"/>
	<rdf:li rdf:resource="http://influxdb.com/blog/2014/09/26/one-year-of-influxdb-and-the-road-to-1_0.html"/>
	<rdf:li rdf:resource="https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud"/>
	<rdf:li rdf:resource="https://www.statuspage.io/"/>
	<rdf:li rdf:resource="http://fractio.nl/2014/08/26/cardiac-alarms-and-ops/"/>
	<rdf:li rdf:resource="http://blog.factual.com/profiling-hadoop-jobs-with-riemann"/>
	<rdf:li rdf:resource="http://www.ebaytechblog.com/2014/03/11/rest-commander-scalable-web-server-management-and-monitoring/#.U9bM0YBdXno"/>
	<rdf:li rdf:resource="https://github.com/mariusaeriksen/heapster"/>
	<rdf:li rdf:resource="http://blog.librato.com/posts/2014/7/16/metrics-driven-development"/>
	<rdf:li rdf:resource="http://go.boundary.com/10freeserversprereg"/>
	<rdf:li rdf:resource="http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html"/>
	<rdf:li rdf:resource="http://riltsken.github.io/devops/infrastructure/monitoring/2014/04/19/making-runbooks-more-useful-by-exposing-them-through-monitoring.html"/>
	<rdf:li rdf:resource="https://deadmanssnitch.com/"/>
	<rdf:li rdf:resource="https://www.google.com/transparencyreport/traffic/explorer/?r=US&amp;l=EVERYTHING"/>
	<rdf:li rdf:resource="http://word.bitly.com/post/74839060954/ten-things-to-monitor"/>
	<rdf:li rdf:resource="http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be"/>
	<rdf:li rdf:resource="https://vividcortex.com/blog/2013/10/14/what-should-i-monitor/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/">
    <title>xcapture and xtop</title>
    <dc:date>2025-09-16T13:59:07+00:00</dc:date>
    <link>https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["0x.Tools: X-Ray vision for Linux systems".  Linux Performance Analysis with Modern eBPF and DuckDB; dig into the captured DuckDB files using "xtop":

"xtop is like the Linux top tool, but extended with x-ray vision and ability to view your performance data from any chosen angle [..]. This enables dimensional performance analysis on Linux and tools like top for wall-clock time and much more. You can use it for system level overview and drill down into indivual threads’ activity and even into kernel events like lock waits or memory stalls."]]></description>
<dc:subject>os debugging sysadmin ops monitoring xtop xcapture ebpf linux duckdb syscalls</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b730ad37aa33/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:os"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xtop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xcapture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebpf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duckdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:syscalls"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/remuslazar/homeassistant-carwings">
    <title>remuslazar/homeassistant-carwings</title>
    <dc:date>2024-07-23T08:49:30+00:00</dc:date>
    <link>https://github.com/remuslazar/homeassistant-carwings</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A new replacement HomeAssistant Integration "to access Nissan Connect EV Services" -- to replace the now-discontinued "nissan_leaf" integration.]]></description>
<dc:subject>todo homeassistant nissan leaf cars automation monitoring smarthome home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9bd9c5690f8b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:todo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:homeassistant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nissan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leaf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smarthome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/louislam/uptime-kuma">
    <title>louislam/uptime-kuma</title>
    <dc:date>2024-02-26T12:11:22+00:00</dc:date>
    <link>https://github.com/louislam/uptime-kuma</link>
    <dc:creator>jm</dc:creator><description><![CDATA["A fancy self-hosted [network] monitoring tool".  This is very pretty, offers a compellingly wide
set of uptime monitoring features including HTTPS cert validation, can notify via Slack or Telegram,
and is self-hosted as a Docker container:

- Monitoring uptime for HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Ping / DNS Record / Push / Steam Game Server / Docker Containers;
- Fancy, Reactive, Fast UI/UX;
- Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services, click here for the full list
- 20-second intervals.

If I hadn't already built out a load of uptime monitoring, I might add this one.  I may just add it anyway,
as you can never have too much monitoring, right?

(via Tristam on ITC Slack)]]></description>
<dc:subject>monitoring uptime network-monitoring networking ops via:itc via:tristam</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:01d82b0fa274/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network-monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:tristam"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://berthub.eu/articles/posts/client-side-scanning-dutch-parliament/">
    <title>Bert Hubert on Chat Control</title>
    <dc:date>2023-10-12T17:21:00+00:00</dc:date>
    <link>https://berthub.eu/articles/posts/client-side-scanning-dutch-parliament/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A transcript of his submission to the Dutch parliamentary hearing on EU Chat Control and Client Side Scanning -- this is very good.

<blockquote>now we are talking about 500 million Europeans, and saying, “Let’s just apply those scanners!” That is incredible. ... If we approve this as a country, if we as the Netherlands vote in favour of this in Europe and say, “Do it,” we will cross a threshold that we have never crossed before.

Namely, every European must be monitored with a computer program, with a technology [...] of which the vast, overwhelming majority of scientists have said, “It is not finished.” I mentioned earlier the example that the Dutch National Forensic Institute says, “We cannot do this by hand.” The EU has now said, “Our computer can do that.”

420 scientists have signed a petition saying, “We know this technology, some of us invented it, we just can’t do it.” We can’t even make a reliable spam filter. Making a spam filter is exactly the same technology, by the way, but then much easier. It just doesn’t work that well, but the consequences aren’t that scary for a spam filter.

Nevertheless, there are now MPs who say, “Well, I feel this is going to work. I have confidence in this.” While the scientists, including the real scientists who came here tonight, say, “Well, we don’t see how this could work well enough”.

And then government then says, “Let’s start this experiment with those 500 million Europeans.”</blockquote>

]]></description>
<dc:subject>eu scanning css chatcontrol internet monitoring surveillance bert-hubert</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b8823261c362/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scanning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chatcontrol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bert-hubert"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.esbnetworks.ie/existing-connections/meters-and-readings/my-smart-data">
    <title>My Smart Data </title>
    <dc:date>2022-11-21T11:22:30+00:00</dc:date>
    <link>https://www.esbnetworks.ie/existing-connections/meters-and-readings/my-smart-data</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ESB Networks is (finally) offering end-users access to their smart electricity meter data with 30-minute granularity]]></description>
<dc:subject>smart-meters esb electricity consumption monitoring ireland</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:279cc28c14fe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smart-meters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:esb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:electricity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consumption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hveem.no/visualizing-latency-variance-with-grafana">
    <title>Visualizing latency variance with grafana</title>
    <dc:date>2022-10-03T17:07:00+00:00</dc:date>
    <link>https://hveem.no/visualizing-latency-variance-with-grafana</link>
    <dc:creator>jm</dc:creator><description><![CDATA[displaying percentiles in the style of SmokePing]]></description>
<dc:subject>grafana influxdb monitoring smokeping dataviz</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d4455d46fd68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:influxdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smokeping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://brunty.me/post/energy-monitoring-2022-edition/">
    <title>Energy Monitoring: 2022 Edition</title>
    <dc:date>2022-09-07T12:06:04+00:00</dc:date>
    <link>https://brunty.me/post/energy-monitoring-2022-edition/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[home energy monitoring using HomeAssistant, MQTT, and a set of power-monitoring smart plugs preflashed with the open Tasmota firmware.  This is all very practical, and the power-socket-based approach means no rewiring is necessary.  I think this is the best UI I've seen so far for a home energy optimization system]]></description>
<dc:subject>home energy monitoring tasmota plugs electricity homeassistant</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7ed8494cc907/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tasmota"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:plugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:electricity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:homeassistant"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pyroscope.io/">
    <title>Pyroscope</title>
    <dc:date>2022-09-01T11:37:13+00:00</dc:date>
    <link>https://pyroscope.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Open Source Continuous Profiling Platform" -- continuous profiling, as has been used in companies like Twitter for a while.  This looks pretty practical though, due to some key features:

<blockquote>Lightning Fast - Doesn't matter if you're looking at 10 seconds or 10 months of profiling data — the queries are always fast thanks to our custom designed storage engine.

Minimum Overhead - Pyroscope doesn't affect performance of your applications, thanks to the use of sampling profiling technology.

Cost-Effective - Pyroscope uses a custom data storage engine and stores profiling data very efficiently, making it economically viable to store profiling data from all of your apps for years.</blockquote>

]]></description>
<dc:subject>monitoring observability profiling pyroscope continuous-profiling performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3e4fd17a7bf9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:observability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pyroscope"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:continuous-profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.browse.ai/">
    <title>Browse.ai</title>
    <dc:date>2022-08-10T17:07:19+00:00</dc:date>
    <link>https://www.browse.ai/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Scrape and Monitor Data from Any Website with No Code" -- looks like an interesting approach to web scraping, with a free plan]]></description>
<dc:subject>scraping web monitoring http</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d287c7100183/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.sciencedirect.com/science/article/pii/S0048969722029254">
    <title>SARS-CoV-2 variant trends in Ireland: Wastewater-based epidemiology and clinical surveillance - ScienceDirect</title>
    <dc:date>2022-05-31T08:11:25+00:00</dc:date>
    <link>https://www.sciencedirect.com/science/article/pii/S0048969722029254</link>
    <dc:creator>jm</dc:creator><description><![CDATA['We have demonstrated that SARS-CoV-2 wastewater monitoring data from a single large WWTP in Dublin reflected case data in the greater Dublin area. Moreover, the surveillance of VOCs in this WWTP reflected the results of clinical sample sequencing and also preceded, further demonstrating the potential utility of this approach to SARS-CoV-2 surveillance.']]></description>
<dc:subject>dublin ireland diseases monitoring sars-cov-2 covid-19 water poop sewage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8c6b4f4274f5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diseases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sars-cov-2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:covid-19"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:water"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:poop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sewage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nelsonslog.wordpress.com/2022/01/20/my-custom-solar-monitoring-system-pvs6/">
    <title>My custom solar monitoring system (PVS6)</title>
    <dc:date>2022-01-21T09:48:05+00:00</dc:date>
    <link>https://nelsonslog.wordpress.com/2022/01/20/my-custom-solar-monitoring-system-pvs6/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nelson's telegraf/grafana setup for monitoring his domestic solar power setup. Very nice indeed, I'll be taking some inspiration from this when I (finally) get around to getting panels on my roof]]></description>
<dc:subject>solar-power solar home graphs grafana dashboards monitoring telegraf via:nelson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e52ca6a193d1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:solar-power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:solar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dashboards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:telegraf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://visualping.io/">
    <title>Visualping</title>
    <dc:date>2022-01-06T10:30:53+00:00</dc:date>
    <link>https://visualping.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Website change detection, monitoring and alerts" - with a very friendly UX. nicely done]]></description>
<dc:subject>monitoring tools web alerting change-detection diffs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f9991be67017/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:change-detection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diffs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/hubblo-org/scaphandre/">
    <title>scaphandre</title>
    <dc:date>2021-01-12T09:46:55+00:00</dc:date>
    <link>https://github.com/hubblo-org/scaphandre/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Electrical power consumption metrology agent. Let scaph dive and bring back the metrics that will help you make your systems and applications more sustainable!</blockquote>

]]></description>
<dc:subject>monitoring metrics power energy sustainability green ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:63d4f4e3bb76/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:green"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/">
    <title>Building dashboards for operational visibility | Amazon Builders' Library</title>
    <dc:date>2020-08-09T22:04:28+00:00</dc:date>
    <link>https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fantastic set of tips for metric dashboard construction, from John O'Shea]]></description>
<dc:subject>dashboards aws monitoring metrics alerts amazon</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf2682c8188c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dashboards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hpsc.ie/a-z/respiratory/influenza/seasonalinfluenza/surveillance/influenzasurveillancereports/20192020season/">
    <title>2019/2020 Season - Health Protection Surveillance Centre</title>
    <dc:date>2020-02-25T16:04:17+00:00</dc:date>
    <link>https://www.hpsc.ie/a-z/respiratory/influenza/seasonalinfluenza/surveillance/influenzasurveillancereports/20192020season/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The HSE's official reports for influenza monitoring for this 'flu season. Impressive]]></description>
<dc:subject>hse monitoring diseases outbreaks flu influenza health medicine ireland</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a7fd5ff86566/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diseases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outbreaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:influenza"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://square.github.io/cubism/">
    <title>Cubism.js</title>
    <dc:date>2020-02-10T12:06:19+00:00</dc:date>
    <link>https://square.github.io/cubism/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A minimalist dashboard style using horizon charts:

<blockquote>Horizon charts reduce vertical space without losing resolution. Larger values are overplotted in successively darker colors, while negative values are offset to descend from the top. As you increase the number of colors, you reduce the required vertical space [...] .  By combining position and color, horizon charts improve perception: position is highly effective at discriminating small changes, while color differentiates large changes. To further increase data density, Cubism favors per-pixel metrics where each pixel encodes a distinct point in time. Cubism also includes thoughtful default colors by Cynthia Brewer.</blockquote>

]]></description>
<dc:subject>charts javascript visualization d3 charting graphs horizon-charts ui monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9282a22da2ab/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:visualization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:d3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:horizon-charts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/pdf/2001.06561.pdf">
    <title>Circllhist</title>
    <dc:date>2020-02-10T11:59:56+00:00</dc:date>
    <link>https://arxiv.org/pdf/2001.06561.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A Log-Linear Histogram Data Structure for IT Infrastructure Monitoring, Heinrich Hartmann, Theo Schlossnagle, (Submitted on 17 Jan 2020).

The circllhist histogram is a fast and memory efficient data structure for summarizing large numbers of latency measurements. It is particularly suited for applications in IT infrastructure monitoring, and provides nano-second data insertion, full mergeability, accurate approximation of quantiles with a-priori bounds on the relative error.

Open-source implementations are available for C/lua/python/Go/Java/JavaScript.'

The paper compares it against 'alternative data-structures which are employed in practice for aggregated quantile calculations: Prometheus Histograms, t-digest, [Gil Tene's] HDR Histograms, and DDSketches']]></description>
<dc:subject>histograms aggregation quantiles percentiles measurement graphs data-structures summaries latency monitoring approximation papers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:763bb560c156/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:histograms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aggregation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:summaries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://sysdig.com/blog/golden-signals-kubernetes/">
    <title>How to monitor Golden signals in Kubernetes</title>
    <dc:date>2020-01-09T17:19:22+00:00</dc:date>
    <link>https://sysdig.com/blog/golden-signals-kubernetes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Most of this doc is Kubernetes specific, but this "golden signals" idea is interesting; basically, the four metrics of requests per second, average request latency, CPU usage on service fleet, errors per second.  I would modify by adding the P99 or P99.9 request latency, and representing errors per second as a proportion of that period's request-per-second figure.]]></description>
<dc:subject>kubernetes monitoring sysdig golden-data k8s golden-signals metrics latency errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c8f356dfeae1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysdig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golden-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golden-signals"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.theguardian.com/info/developer-blog/2016/dec/05/testing-in-production-how-we-combined-tests-with-monitoring">
    <title>Testing in Production: How we combined tests with monitoring</title>
    <dc:date>2020-01-06T11:43:49+00:00</dc:date>
    <link>https://www.theguardian.com/info/developer-blog/2016/dec/05/testing-in-production-how-we-combined-tests-with-monitoring</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The Guardian Digital team's write-up on their "test in prod" setup -- post-release monitoring through running integration test suites.  We do the same in Swrve, calling our suites the "canary tests", and it works really well for us.]]></description>
<dc:subject>testing monitoring ops devops the-guardian prod production releases</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:083ed1350efa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:the-guardian"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prod"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:releases"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring/">
    <title>Stack Overflow: How We Do Monitoring - 2018 Edition</title>
    <dc:date>2019-01-21T14:31:56+00:00</dc:date>
    <link>https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting to see how the other half lives, as Stack Overflow is a .NET shop]]></description>
<dc:subject>logging monitoring stack-overflow dotnet ops metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1fc7afb1f694/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stack-overflow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dotnet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.livpi.com/store/c1/Featured_Products.html">
    <title>LiV Pi</title>
    <dc:date>2018-10-23T13:23:40+00:00</dc:date>
    <link>http://www.livpi.com/store/c1/Featured_Products.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Air quality sensor board for Raspberry Pis, with a good quality self-calibrating NDIR CO2 sensor]]></description>
<dc:subject>co2 air quality monitoring metrics health home raspberry-pi hardware to-get</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b2bfce088278/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:co2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:air"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:to-get"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://improbable.io/games/blog/thanos-prometheus-at-scale">
    <title>Thanos: Prometheus at Scale</title>
    <dc:date>2018-05-18T21:54:18+00:00</dc:date>
    <link>https://improbable.io/games/blog/thanos-prometheus-at-scale</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting]]></description>
<dc:subject>devops monitoring tools prometheus ops metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3588acf20d03/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.datadoghq.com/blog/rabbitmq-monitoring/">
    <title>Key metrics for RabbitMQ monitoring</title>
    <dc:date>2018-01-29T10:46:24+00:00</dc:date>
    <link>https://www.datadoghq.com/blog/rabbitmq-monitoring/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good suggestions from Datadog]]></description>
<dc:subject>rabbitmq mq monitoring metrics graphite ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e70e84e4c6aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://opensource.googleblog.com/2018/01/opencensus.html">
    <title>OpenCensus: A Stats Collection and Distributed Tracing Framework</title>
    <dc:date>2018-01-18T14:24:25+00:00</dc:date>
    <link>https://opensource.googleblog.com/2018/01/opencensus.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Google open sourcing their internal Census lib for service metrics and distributed tracing]]></description>
<dc:subject>google monitoring service-metrics metrics census opencensus open-source tracing zipkin prometheus</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:65886e149118/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:census"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:opencensus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zipkin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/diabetes/comments/7nvufy/my_bedroom_lights_turn_on_when_my_blood_sugar/">
    <title>My bedroom lights turn on when my blood sugar goes low! (Dexcom, Nightscout and IFTTT) : diabetes</title>
    <dc:date>2018-01-04T23:35:19+00:00</dc:date>
    <link>https://www.reddit.com/r/diabetes/comments/7nvufy/my_bedroom_lights_turn_on_when_my_blood_sugar/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Now this is a great idea -- IOT to the rescue]]></description>
<dc:subject>iot via:fp via:eatpaste blood health diabetes monitoring home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a09a476be990/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:eatpaste"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blood"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diabetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://sourcegraph.github.io/checkup/">
    <title>Checkup</title>
    <dc:date>2017-12-18T11:34:39+00:00</dc:date>
    <link>https://sourcegraph.github.io/checkup/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Simple uptime monitoring: distributed, self-hosted health checks and status pages' -- stores in S3]]></description>
<dc:subject>go ops monitoring uptime health-checks status-pages status golang s3</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cb7582683d84/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health-checks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:status-pages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:status"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.hostedgraphite.com/2017/07/06/continuous-self-testing-at-hosted-graphite-why-we-send-external-canaries-every-second/">
    <title>Continuous self-testing at Hosted Graphite</title>
    <dc:date>2017-11-14T23:05:56+00:00</dc:date>
    <link>https://blog.hostedgraphite.com/2017/07/06/continuous-self-testing-at-hosted-graphite-why-we-send-external-canaries-every-second/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['why we send external canaries, every second']]></description>
<dc:subject>graphite hostedgraphite monitoring canaries udp alerting ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:398772f5b2a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hostedgraphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:canaries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://drive.google.com/file/d/0BzRE_fwreoDQNzUybnRFOHpWZTA/view">
    <title>'Monitoring Cloudflare's planet-scale edge network with Prometheus' (preso)</title>
    <dc:date>2017-09-25T09:51:26+00:00</dc:date>
    <link>https://drive.google.com/file/d/0BzRE_fwreoDQNzUybnRFOHpWZTA/view</link>
    <dc:creator>jm</dc:creator><description><![CDATA[from SRECon EMEA 2017; how Cloudflare are replacing Nagios with Prometheus and grafana]]></description>
<dc:subject>metrics monitoring alerting prometheus grafana nagios</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7a0ed0cf1b59/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nagios"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html">
    <title>Linux Load Averages: Solving the Mystery</title>
    <dc:date>2017-08-21T13:17:17+00:00</dc:date>
    <link>http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice bit of OS archaeology by Brendan Gregg.

<blockquote>In 1993, a Linux engineer found a nonintuitive case with load averages, and with a three-line patch changed them forever from "CPU load averages" to what one might call "system load averages." His change included tasks in the uninterruptible state, so that load averages reflected demand for disk resources and not just CPUs. These system load averages count the number of threads working and waiting to work, and are summarized as a triplet of exponentially-damped moving sum averages that use 1, 5, and 15 minutes as constants in an equation. This triplet of numbers lets you see if load is increasing or decreasing, and their greatest value may be for relative comparisons with themselves.</blockquote>

]]></description>
<dc:subject>load monitoring linux unix performance ops brendan-gregg history cpu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:00a0f4ee73d7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:brendan-gregg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bcicen.github.io/ctop/">
    <title>ctop</title>
    <dc:date>2017-03-12T23:07:40+00:00</dc:date>
    <link>https://bcicen.github.io/ctop/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Top for containers (ie Docker)]]></description>
<dc:subject>docker containers top ops go monitoring cpu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d168e83ae1a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:top"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://code.facebook.com/posts/952820474848503/beringei-a-high-performance-time-series-storage-engine/">
    <title>Beringei: A high-performance time series storage engine | Engineering Blog | Facebook Code</title>
    <dc:date>2017-02-06T12:08:26+00:00</dc:date>
    <link>https://code.facebook.com/posts/952820474848503/beringei-a-high-performance-time-series-storage-engine/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Beringei is different from other in-memory systems, such as memcache, because it has been optimized for storing time series data used specifically for health and performance monitoring. We designed Beringei to have a very high write rate and a low read latency, while being as efficient as possible in using RAM to store the time series data. In the end, we created a system that can store all the performance and monitoring data generated at Facebook for the most recent 24 hours, allowing for extremely fast exploration and debugging of systems and services as we encounter issues in production.

Data compression was necessary to help reduce storage overhead. We considered several existing compression schemes and rejected the techniques that applied only to integer data, used approximation techniques, or needed to operate on the entire dataset. Beringei uses a lossless streaming compression algorithm to compress points within a time series with no additional compression used across time series. Each data point is a pair of 64-bit values representing the timestamp and value of the counter at that time. Timestamps and values are compressed separately using information about previous values. Timestamp compression uses a delta-of-delta encoding, so regular time series use very little memory to store timestamps.

From analyzing the data stored in our performance monitoring system, we discovered that the value in most time series does not change significantly when compared to its neighboring data points. Further, many data sources only store integers (despite the system supporting floating point values). Knowing this, we were able to tune previous academic work to be easier to compute by comparing the current value with the previous value using XOR, and storing the changed bits. Ultimately, this algorithm resulted in compressing the entire data set by at least 90 percent.</blockquote>

]]></description>
<dc:subject>beringei compression facebook monitoring tsd time-series storage architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3d15d674f951/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beringei"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ispokemongodownornot.com/">
    <title>Is Pokémon GO down or not?</title>
    <dc:date>2016-07-20T10:14:40+00:00</dc:date>
    <link>http://ispokemongodownornot.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[(a) 83.5% uptime over 24 hours.  GOOD JOB

(b) excellent marketing by Datadog!]]></description>
<dc:subject>datadog games monitoring pokemon-go pokemon uptime</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a69910d88699/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datadog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pokemon-go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pokemon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit">
    <title>My Philosophy on Alerting</title>
    <dc:date>2016-07-14T14:53:47+00:00</dc:date>
    <link>https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit</link>
    <dc:creator>jm</dc:creator><description><![CDATA['based my observations while I was a Site Reliability Engineer at Google', courtesy of Rob Ewaschuk <rob@infinitepigeons.org>.  Seem pretty reasonable]]></description>
<dc:subject>monitoring sysadmin alerting alerts nagios pager ops sre rob-ewaschuk</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6c245de62c9b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nagios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pager"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rob-ewaschuk"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.raintank.io/dear-graphite-users-and-developers/">
    <title>Raintank investing in Graphite</title>
    <dc:date>2016-07-06T09:54:16+00:00</dc:date>
    <link>https://blog.raintank.io/dear-graphite-users-and-developers/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[paying Jason Dixon to work on it, improving the backend, possibly replacing the creaky Whisper format.  great news!]]></description>
<dc:subject>graphite metrics monitoring ops open-source grafana raintank</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f5504b4e51fb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grafana"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raintank"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/apn/key-metrics-for-amazon-aurora/?adbsc=APN_Blog_20160512_61520166&amp;adbid=730767018157170688&amp;adbpl=tw&amp;adbpr=509089629">
    <title>Key Metrics for Amazon Aurora | AWS Partner Network (APN) Blog</title>
    <dc:date>2016-05-13T11:02:51+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/apn/key-metrics-for-amazon-aurora/?adbsc=APN_Blog_20160512_61520166&amp;adbid=730767018157170688&amp;adbpl=tw&amp;adbpr=509089629</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Very DataDog-oriented, but some decent tips on monitorable metrics here]]></description>
<dc:subject>datadog metrics aurora aws rds monitoring ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:06d10a828d7e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datadog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://coreos.com/blog/coreos-and-prometheus-improve-cluster-monitoring.html">
    <title>CoreOS and Prometheus: Building monitoring for the next generation of cluster infrastructure</title>
    <dc:date>2016-05-01T09:19:07+00:00</dc:date>
    <link>https://coreos.com/blog/coreos-and-prometheus-improve-cluster-monitoring.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ooh, this is a great plan.  :applause:

<blockquote>Enabling GIFEE — Google Infrastructure for Everyone Else — is a primary mission at CoreOS, and open source is key to that goal. [....]

Prometheus was initially created to handle monitoring and alerting in modern microservice architectures. It steadily grew to fit the wider idea of cloud native infrastructure. Though it was not intentional in the original design, Prometheus and Kubernetes conveniently share the key concept of identifying entities by labels, making the semantics of monitoring Kubernetes clusters simple. As we discussed previously on this blog, Prometheus metrics formed the basis of our analysis of Kubernetes scheduler performance, and led directly to improvements in that code. Metrics are essential not just to keep systems running, but also to analyze and improve application behavior.

All things considered, Prometheus was an obvious choice for the next open source project CoreOS wanted to support and improve with internal developers committed to the code base.</blockquote>

]]></description>
<dc:subject>monitoring coreos prometheus metrics clustering ops gifee google kubernetes</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c041f696601f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coreos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clustering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gifee"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/firehol/netdata">
    <title>firehol/netdata: Real-time performance monitoring, done right!</title>
    <dc:date>2016-03-30T13:00:25+00:00</dc:date>
    <link>https://github.com/firehol/netdata</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Lovely Bootstrap-based UI, easy to install (via Mark Kenny)]]></description>
<dc:subject>via:markkenny linux monitoring ops netdata sysstat metrics graphing ui</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:871c10a92d95/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:markkenny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netdata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysstat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.twitter.com/2016/observability-at-twitter-technical-overview-part-ii">
    <title>Observability at Twitter: technical overview, part II</title>
    <dc:date>2016-03-29T11:10:48+00:00</dc:date>
    <link>https://blog.twitter.com/2016/observability-at-twitter-technical-overview-part-ii</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting to me mainly for this tidbit which makes my own prejudices:

<blockquote>“Pull” vs “push” in metrics collection: At the time of our previous blog post, all our metrics were collected by “pulling” from our collection agents. We discovered two main issues:

* There is no easy way to differentiate service failures from collection agent failures. Service response time out and missed collection request are both manifested as empty time series.
* There is a lack of service quality insulation in our collection pipeline. It is very difficult to set an optimal collection time out for various services. A long collection time from one single service can cause a delay for other services that share the same collection agent.

In light of these issues, we switched our collection model from “pull” to “push” and increased our service isolation. Our collection agent on each host only collects metrics from services running on that specific host. Additionally, each collection agent sends separate collection status tracking metrics in addition to the metrics emitted by the services.

We have seen a significant improvement in collection reliability with these changes. However, as we moved to self service push model, it becomes harder to project the request growth. In order to solve this problem, we plan to implement service quota to address unpredictable/unbounded growth.</blockquote>

]]></description>
<dc:subject>pull push metrics tcp stacks monitoring agents twitter fault-tolerance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5023179ebada/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pull"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:push"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:agents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://prometheus.io/blog/2016/03/23/interview-with-life360/">
    <title>Life360 testimonial for Prometheus</title>
    <dc:date>2016-03-24T13:21:13+00:00</dc:date>
    <link>http://prometheus.io/blog/2016/03/23/interview-with-life360/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Now this is a BIG thumbs up: <blockquote>'Prometheus has been known to us for a while, and we have been tracking it and reading about the active development, and at a point (a few months back) we decided to start evaluating it for production use.  The PoC results were incredible. The monitoring coverage of MySQL was amazing, and we also loved the JMX monitoring for Cassandra, which had been sorely lacking in the past.'</blockquote>

]]></description>
<dc:subject>metrics monitoring time-series prometheus testimonials life360 cassandra jmx mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4405c9925a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testimonials"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:life360"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/">
    <title>Heroic</title>
    <dc:date>2015-12-09T11:35:37+00:00</dc:date>
    <link>https://labs.spotify.com/2015/11/17/monitoring-at-spotify-introducing-heroic/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Spotify wrote their own metrics store on ElasticSearch and Cassandra.  Sounds very similar to Prometheus]]></description>
<dc:subject>cassandra elasticsearch spotify monitoring metrics heroic</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cdb427d86615/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticsearch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spotify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heroic"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.vividcortex.com/blog/why-percentiles-dont-work-the-way-you-think">
    <title>Why Percentiles Don’t Work the Way you Think</title>
    <dc:date>2015-12-09T11:26:47+00:00</dc:date>
    <link>https://www.vividcortex.com/blog/why-percentiles-dont-work-the-way-you-think</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Baron Schwartz on metrics, percentiles, and aggregation. +1, although as a HN commenter noted, quantile digests are probably the better fix]]></description>
<dc:subject>performance percentiles quantiles statistics metrics monitoring baron-schwartz vividcortex</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c441c328a979/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:baron-schwartz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vividcortex"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://en.wikipedia.org/wiki/Floating_car_data">
    <title>Floating car data</title>
    <dc:date>2015-11-20T13:51:52+00:00</dc:date>
    <link>https://en.wikipedia.org/wiki/Floating_car_data</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Floating car data (FCD), also known as floating cellular data, is a method to determine the traffic speed on the road network. It is based on the collection of localization data, speed, direction of travel and time information from mobile phones in vehicles that are being driven. These data are the essential source for traffic information and for most intelligent transportation systems (ITS). This means that every vehicle with an active mobile phone acts as a sensor for the road network. Based on these data, traffic congestion can be identified, travel times can be calculated, and traffic reports can be rapidly generated. In contrast to traffic cameras, number plate recognition systems, and induction loops embedded in the roadway, no additional hardware on the road network is necessary.</blockquote>

]]></description>
<dc:subject>surveillance cars driving mobile-phones phones travel gsm monitoring anpr alpr traffic</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c0e3462dec97/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surveillance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:driving"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile-phones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:travel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gsm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:anpr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alpr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:traffic"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.vividcortex.com/blog/2015/11/05/nobody-loves-graphite-anymore/">
    <title>Nobody Loves Graphite Anymore - VividCortex</title>
    <dc:date>2015-11-05T22:22:21+00:00</dc:date>
    <link>https://www.vividcortex.com/blog/2015/11/05/nobody-loves-graphite-anymore/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Graphite has a place in our current monitoring stack, and together with StatsD will always have a special place in the hearts of DevOps practitioners everywhere, but it’s not representative of state-of-the-art in the last few years. Graphite is where the puck was in 2010. If you’re skating there, you’re missing the benefits of modern monitoring infrastructure.

The future I foresee is one where time series capabilities (the raw power needed, which I described in my time series requirements blog post, for example) are within everyone’s reach. That will be considered table stakes, whereas now it’s pretty revolutionary.</blockquote>

Like I've been saying -- we need Time Series As A Service!  This should be undifferentiated heavy lifting.]]></description>
<dc:subject>graphite tsd time-series vividcortex statsd ops monitoring metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f81dace94111/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vividcortex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/message/5467D2/">
    <title>Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region</title>
    <dc:date>2015-09-23T12:48:44+00:00</dc:date>
    <link>https://aws.amazon.com/message/5467D2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Painful to read, but: tl;dr: monitoring oversight, followed by a transient network glitch triggering IPC timeouts, which increased load due to lack of circuit breakers, creating a cascading failure]]></description>
<dc:subject>aws postmortem outages dynamodb ec2 post-mortems circuit-breakers monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f804599be513/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:circuit-breakers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.eightypercent.net/post/layers-in-the-stack.html">
    <title>Anatomy of a Modern Production Stack</title>
    <dc:date>2015-09-18T16:37:49+00:00</dc:date>
    <link>http://www.eightypercent.net/post/layers-in-the-stack.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting post, but I think it falls into a common trap for the xoogler or ex-Amazonian -- assuming that all the BigCo mod cons are required to operate, when some are luxuries than can be skipped for a few years to get some real products built]]></description>
<dc:subject>architecture ops stack docker containerization deployment containers rkt coreos prod monitoring xooglers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6929918b25c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containerization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rkt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coreos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prod"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xooglers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blogs.aws.amazon.com/bigdata/post/Tx3ET30EGDKUUI2/Implementing-Efficient-and-Reliable-Producers-with-the-Amazon-Kinesis-Producer-L">
    <title>Implementing Efficient and Reliable Producers with the Amazon Kinesis Producer Library - AWS Big Data Blog</title>
    <dc:date>2015-08-07T10:01:09+00:00</dc:date>
    <link>https://blogs.aws.amazon.com/bigdata/post/Tx3ET30EGDKUUI2/Implementing-Efficient-and-Reliable-Producers-with-the-Amazon-Kinesis-Producer-L</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good advice on production-quality, decent-scale usage of Kinesis in Java with the official library: batching, retries, partial failures, backoff, and monitoring. (Also, jaysus, the AWS Cloudwatch API is awful, looking at this!)]]></description>
<dc:subject>kpl aws kinesis tips java batching streaming production cloudwatch monitoring coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:20af3897603a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kpl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kinesis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:batching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudwatch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.linkedin.com/sre/introducing-nurse-auto-remediation-linkedin">
    <title>Introducing Nurse: Auto-Remediation at LinkedIn</title>
    <dc:date>2015-08-04T12:52:06+00:00</dc:date>
    <link>https://engineering.linkedin.com/sre/introducing-nurse-auto-remediation-linkedin</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting to hear about auto-remediation in prod -- we built a (very targeted) auto-remediation system in Amazon on the Network Monitoring team, but this is much bigger in focus]]></description>
<dc:subject>nurse auto-remediation outages linkedin ops monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f862fe9da2a1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nurse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:auto-remediation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.datadoghq.com/blog/how-to-monitor-nginx/">
    <title>How to monitor NGINX</title>
    <dc:date>2015-07-15T09:38:28+00:00</dc:date>
    <link>https://www.datadoghq.com/blog/how-to-monitor-nginx/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[From DataDog.  See also "How to collect NGINX metrics": https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/]]></description>
<dc:subject>nginx monitoring metrics howto datadog ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:159b82cf2424/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:howto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datadog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/aragozin/jvm-tools">
    <title>sjk</title>
    <dc:date>2015-06-25T16:49:38+00:00</dc:date>
    <link>https://github.com/aragozin/jvm-tools</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a command line tool for JVM diagnostic troubleshooting and profiling.</blockquote>

]]></description>
<dc:subject>java jvm monitoring commandline jmx sjk tools ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ecc9f104166/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:commandline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sjk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://githubengineering.com/brubeck/">
    <title>Brubeck, a statsd-compatible metrics aggregator - GitHub Engineering</title>
    <dc:date>2015-06-23T13:27:18+00:00</dc:date>
    <link>http://githubengineering.com/brubeck/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[GitHub's statsd replacement in C]]></description>
<dc:subject>github monitoring statsd c rewrites ops metrics</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d824ce3cab14/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rewrites"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gist.github.com/acolyer/95ef23802803cb8b4eb5">
    <title>Internet Scale Services Checklist</title>
    <dc:date>2015-04-21T11:39:07+00:00</dc:date>
    <link>https://gist.github.com/acolyer/95ef23802803cb8b4eb5</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good aspirational checklist, inspired heavily by James Hamilton's seminal 2007 paper, "On Designing And Deploying Internet-Scale Services"]]></description>
<dc:subject>james-hamilton checklists ops internet-scale architecture operability monitoring reliability availability uptime aspirations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:827aeebe6695/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:james-hamilton"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:checklists"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet-scale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:operability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aspirations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://techblog.netflix.com/2015/04/introducing-vector-netflixs-on-host.html">
    <title>Introducing Vector: Netflix's On-Host Performance Monitoring Tool</title>
    <dc:date>2015-04-08T16:11:22+00:00</dc:date>
    <link>http://techblog.netflix.com/2015/04/introducing-vector-netflixs-on-host.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It gives pinpoint real-time performance metric visibility to engineers working on specific hosts -- basically sending back system-level performance data to their browser, where a client-side renderer turns it into a usable dashboard.  Essentially the idea is to replace having to ssh onto instances, run "top", systat, iostat, and so on.]]></description>
<dc:subject>vector netflix performance monitoring sysstat top iostat netstat metrics ops dashboards real-time linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d0c08977fb73/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vector"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysstat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:top"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iostat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netstat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dashboards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:real-time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/jallspaw/etsy-codeascraft-allspaw1">
    <title>Outages, PostMortems, and Human Error 101</title>
    <dc:date>2015-04-04T09:32:24+00:00</dc:date>
    <link>http://www.slideshare.net/jallspaw/etsy-codeascraft-allspaw1</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good basic pres from John Allspaw, covering the basics of tier-one tech incident response -- defining the 5 severity levels; root cause analysis techniques (to Five-Whys or not); and the importance of service metrics]]></description>
<dc:subject>devops monitoring ops five-whys allspaw slides etsy codeascraft incident-response incidents severity root-cause postmortems outages reliability techops tier-one-support</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1b513074b706/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:five-whys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allspaw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:etsy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:codeascraft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incident-response"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incidents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:severity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:root-cause"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:techops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tier-one-support"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://hekad.readthedocs.org/en/v0.9.0/">
    <title>Heka</title>
    <dc:date>2015-03-13T11:39:13+00:00</dc:date>
    <link>http://hekad.readthedocs.org/en/v0.9.0/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>an open source stream processing software system developed by Mozilla. Heka is a “Swiss Army Knife” type tool for data processing, useful for a wide variety of different tasks, such as:

Loading and parsing log files from a file system.
Accepting statsd type metrics data for aggregation and forwarding to upstream time series data stores such as graphite or InfluxDB.
Launching external processes to gather operational data from the local system.
Performing real time analysis, graphing, and anomaly detection on any data flowing through the Heka pipeline.
Shipping data from one location to another via the use of an external transport (such as AMQP) or directly (via TCP).
Delivering processed data to one or more persistent data stores.</blockquote>

Via feylya on twitter. Looks potentially nifty]]></description>
<dc:subject>heka mozilla monitoring metrics via:feylya ops statsd graphite stream-processing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6bb38322d5e4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mozilla"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:feylya"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stream-processing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://influxdb.com/blog/2014/09/26/one-year-of-influxdb-and-the-road-to-1_0.html">
    <title>One year of InfluxDB and the road to 1.0</title>
    <dc:date>2015-02-19T22:21:45+00:00</dc:date>
    <link>http://influxdb.com/blog/2014/09/26/one-year-of-influxdb-and-the-road-to-1_0.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>half of the [Monitorama] attendees were employees and entrepreneurs at monitoring, metrics, DevOps, and server analytics companies. Most of them had a story about how their metrics API was their key intellectual property that took them years to develop. The other half of the attendees were developers at larger organizations that were rolling their own DevOps stack from a collection of open source tools. Almost all of them were creating a “time series database” with a bunch of web services code on top of some other database or just using Graphite.  When everyone is repeating the same work, it’s not key intellectual property or a differentiator, it’s a barrier to entry. Not only that, it’s something that is hindering innovation in this space since everyone has to spend their first year or two getting to the point where they can start building something real. It’s like building a web company in 1998. You have to spend millions of dollars and a year building infrastructure, racking servers, and getting everything ready before you could run the application. Monitoring and analytics applications should not be like this.</blockquote>

]]></description>
<dc:subject>graphite monitoring metrics tsd time-series analytics influxdb open-source</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cbe8b281afb6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analytics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:influxdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud">
    <title>Backstage Blog - Prometheus: Monitoring at SoundCloud - SoundCloud Developers</title>
    <dc:date>2015-02-02T00:49:50+00:00</dc:date>
    <link>https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud</link>
    <dc:creator>jm</dc:creator><description><![CDATA[whoa, this is pretty excellent. The major improvement over a graphite-based system would be the multi-dimensional tagging of metrics, which we currently have to do by simply expanding the graphite metric's name to encompass all those dimensions and use searching at query time, inefficiently.]]></description>
<dc:subject>monitoring soundcloud prometheus metrics service-metrics graphite alerting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acbb62360d38/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soundcloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.statuspage.io/">
    <title>StatusPage.io</title>
    <dc:date>2014-11-11T16:49:30+00:00</dc:date>
    <link>https://www.statuspage.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Hosted Status Pages for Your Company'.  We use these guys in $work, and their service is fantastic -- it's a line of javascript in the page template which will easily allow you to add a "service degraded" banner when things go pear-shaped, along with an external status site for when things get really messy.  They've done a good clean job.]]></description>
<dc:subject>monitoring server status outages uptime saas infrastructure</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:177d01ae1b08/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:server"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:status"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infrastructure"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fractio.nl/2014/08/26/cardiac-alarms-and-ops/">
    <title>Applying cardiac alarm management techniques to your on-call</title>
    <dc:date>2014-09-01T09:34:20+00:00</dc:date>
    <link>http://fractio.nl/2014/08/26/cardiac-alarms-and-ops/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An ops-focused take on a recent story about alarm fatigue, and how a Boston hospital dealt with it. When I was in Amazon, many of the teams in our division had a target to reduce false positive pages, with a definite monetary value attached to it, since many teams had "time off in lieu" payments for out-of-hours pages to the on-call staff.  As a result, reducing false-positive pages was reasonably high priority and we dealt with this problem very proactively, with a well-developed sense of how to do so.  It's interesting to see how the outside world is only just starting to look into its amelioration.  (Another benefit of a TOIL policy ;)]]></description>
<dc:subject>ops monitoring sysadmin alerts alarms nagios alarm-fatigue false-positives pages</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:89a98e187218/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alarms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nagios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alarm-fatigue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:false-positives"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pages"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.factual.com/profiling-hadoop-jobs-with-riemann">
    <title>Profiling Hadoop jobs with Riemann</title>
    <dc:date>2014-08-13T16:00:30+00:00</dc:date>
    <link>http://blog.factual.com/profiling-hadoop-jobs-with-riemann</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I’ve built a very simple distributed profiler for soft-real-time telemetry from hundreds to thousands of JVMs concurrently. It’s nowhere near as comprehensive in its analysis as, say, Yourkit, but it can tell you, across a distributed system, which functions are taking the most time, and what their dominant callers are.</blockquote>

Potentially useful.
]]></description>
<dc:subject>riemann profiling aphyr hadoop emr performance monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b55131749671/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riemann"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aphyr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ebaytechblog.com/2014/03/11/rest-commander-scalable-web-server-management-and-monitoring/#.U9bM0YBdXno">
    <title>REST Commander: Scalable Web Server Management and Monitoring</title>
    <dc:date>2014-07-28T22:24:37+00:00</dc:date>
    <link>http://www.ebaytechblog.com/2014/03/11/rest-commander-scalable-web-server-management-and-monitoring/#.U9bM0YBdXno</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>We dynamically monitor and manage a large and rapidly growing number of web servers deployed on our infrastructure and systems. However, existing tools present major challenges when making REST/SOAP calls with server-specific requests to a large number of web servers, and then performing aggregated analysis on the responses. We therefore developed REST Commander, a parallel asynchronous HTTP client as a service to monitor and manage web servers. REST Commander on a single server can send requests to thousands of servers with response aggregation in a matter of seconds. And yes, it is open-sourced at http://www.restcommander.com.

Feature highlights:

Click-to-run with zero installation;
Generic HTTP request template supporting variable-based replacement for sending server-specific requests;
Ability to send the same request to different servers, different requests to different servers, and different requests to the same server;
Maximum concurrency control (throttling) to accommodate server capacity;
Commander itself is also “as a service”: with its powerful REST API, you can define ad-hoc target servers, an HTTP request template, variable replacement, and a regular expression all in a single call. In addition, intuitive step-by-step wizards help you achieve the same functionality through a GUI.</blockquote>

]]></description>
<dc:subject>rest http clients load-testing ebay soap async testing monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5ca168566fa5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clients"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebay"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/mariusaeriksen/heapster">
    <title>mariusaeriksen/heapster</title>
    <dc:date>2014-07-24T09:05:58+00:00</dc:date>
    <link>https://github.com/mariusaeriksen/heapster</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Heapster provides an agent library to do heap profiling for JVM processes with output compatible with Google perftools. The goal of Heapster is to be able to do meaningful (sampled) heap profiling in a production setting.</blockquote>

Used by Twitter in production, apparently.]]></description>
<dc:subject>heap monitoring memory jvm java performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5a7c8a71eb82/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.librato.com/posts/2014/7/16/metrics-driven-development">
    <title>Metrics-Driven Development</title>
    <dc:date>2014-07-22T09:20:12+00:00</dc:date>
    <link>http://blog.librato.com/posts/2014/7/16/metrics-driven-development</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>we believe MDD is equal parts engineering technique and cultural process. It separates the notion of monitoring from its traditional position of exclusivity as an operations thing and places it more appropriately next to its peers as an engineering process. Provided access to real-time production metrics relevant to them individually, both software engineers and operations engineers can validate hypotheses, assess problems, implement solutions, and improve future designs.</blockquote>

Broken down into the following principles: 'Instrumentation-as-Code', 'Single Source of Truth', 'Developers Curate Visualizations and Alerts', 'Alert on What You See', 'Show me the Graph', 'Don’t Measure Everything (YAGNI)'.

We do all of these at Swrve, naturally (a technique I happily stole from Amazon).]]></description>
<dc:subject>metrics coding graphite mdd instrumentation yagni alerting monitoring graphs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2bbaac35dc32/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instrumentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yagni"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://go.boundary.com/10freeserversprereg">
    <title>Boundary's new server monitoring free offering</title>
    <dc:date>2014-07-15T09:14:05+00:00</dc:date>
    <link>http://go.boundary.com/10freeserversprereg</link>
    <dc:creator>jm</dc:creator><description><![CDATA['High resolution, 1 second intervals for all metrics; Fluid analytics, drag any graph to any point in time; Smart alarms to cut down on false positives; Embedded graphs and customizable dashboards; Up to 10 servers for free'

Pre-registration is open now. Could be interesting, although the limit of 10 machines is pretty small for any production usage]]></description>
<dc:subject>boundary monitoring network ops metrics alarms tcp ip netstat</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:175d993187e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:boundary"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alarms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netstat"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html">
    <title>interview with Google VP of SRE Ben Treynor</title>
    <dc:date>2014-05-06T15:00:22+00:00</dc:date>
    <link>http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interviewed by Niall Murphy, no less ;).  Some good info on what Google deems important from an ops/SRE perspective]]></description>
<dc:subject>sre ops devops google monitoring interviews ben-treynor</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c2afc10c4f2c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ben-treynor"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://riltsken.github.io/devops/infrastructure/monitoring/2014/04/19/making-runbooks-more-useful-by-exposing-them-through-monitoring.html">
    <title>Making runbooks more useful by exposing them through monitoring</title>
    <dc:date>2014-04-28T11:20:43+00:00</dc:date>
    <link>http://riltsken.github.io/devops/infrastructure/monitoring/2014/04/19/making-runbooks-more-useful-by-exposing-them-through-monitoring.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice example of an ops runbook wiki for a service]]></description>
<dc:subject>runbooks ops devops monitoring sysadmin documentation wiki</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:39c34d3c51f1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:runbooks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wiki"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://deadmanssnitch.com/">
    <title>Dead Man's Snitch</title>
    <dc:date>2014-04-08T14:05:41+00:00</dc:date>
    <link>https://deadmanssnitch.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a cron job monitoring tool that keeps an eye on your periodic processes and notifies you when something doesn't happen. Daily backups, monthly emails, or cron jobs you need to monitor? Dead Man's Snitch has you covered. Know immediately when one of these processes doesn't work.</blockquote>

via Marc.]]></description>
<dc:subject>alerts cron monitoring sysadmin ops backups alarms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a15af0101f4f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alarms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.google.com/transparencyreport/traffic/explorer/?r=US&amp;l=EVERYTHING">
    <title>Traffic Graph – Google Transparency Report</title>
    <dc:date>2014-02-20T17:43:41+00:00</dc:date>
    <link>https://www.google.com/transparencyreport/traffic/explorer/?r=US&amp;l=EVERYTHING</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is cool.  Google are exposing an aggregated 'all services' hit count time-series graph, broken down by country, as part of their Transparency Report pages]]></description>
<dc:subject>transparency filtering web google http graphs monitoring syria</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:903ee1300110/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transparency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filtering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:syria"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://word.bitly.com/post/74839060954/ten-things-to-monitor">
    <title>10 Things We Forgot to Monitor</title>
    <dc:date>2014-01-29T15:00:43+00:00</dc:date>
    <link>http://word.bitly.com/post/74839060954/ten-things-to-monitor</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a list of not-so-common outage causes which are easy to overlook; swap rate, NTP drift, SSL expiration, fork rate, etc.]]></description>
<dc:subject>nagios metrics ops monitoring systems ntp bitly</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8d0b22e66fef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nagios"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bitly"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be">
    <title>Twitter tech talk video: &quot;Profiling Java In Production&quot;</title>
    <dc:date>2013-12-09T12:44:56+00:00</dc:date>
    <link>http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In this talk Kaushik Srenevasan describes a new, low overhead, full-stack tool (based on the Linux perf profiler and infrastructure built into the Hotspot JVM) we've built at Twitter to solve the problem of dynamically profiling and tracing the behavior of applications (including managed runtimes) in production.</blockquote>

Looks very interesting.  Haven't watched it yet though]]></description>
<dc:subject>twitter tech-talks video presentations java jvm profiling testing monitoring service-metrics performance production hotspot perf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ee6e08004f6c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech-talks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://vividcortex.com/blog/2013/10/14/what-should-i-monitor/">
    <title>&quot;What Should I Monitor?&quot;</title>
    <dc:date>2013-10-15T16:08:14+00:00</dc:date>
    <link>https://vividcortex.com/blog/2013/10/14/what-should-i-monitor/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[slides (lots of slides) from Baron Schwartz' talk at Velocity in NYC.]]></description>
<dc:subject>slides monitoring metrics ops devops baron-schwartz pdf capacity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3a3dc0e93b75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:baron-schwartz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>