<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>monitoring on Me, thinking out loud</title>
    <link>https://blog.straughan.org/topics/monitoring/</link>
    <description>Recent content in monitoring on Me, thinking out loud</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-GB</language>
    <lastBuildDate>Mon, 18 Sep 2017 21:53:01 +0100</lastBuildDate>
    
	<atom:link href="https://blog.straughan.org/topics/monitoring/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Behaviours not Errors</title>
      <link>https://blog.straughan.org/post/behaviours-not-errors/</link>
      <pubDate>Mon, 18 Sep 2017 21:53:01 +0100</pubDate>
      
      <guid>https://blog.straughan.org/post/behaviours-not-errors/</guid>
      <description>Overview Recently, I have been thinking about my preference for structured logging (details on this in to-be-written entry). A trivial but significant aspect of this, is that once you have switched to structured logging, markers like INFO, DEBUG, ERROR,&amp;hellip; don&#39;t help. Simply grouping such a wide range of code paths into these categories is insufficient for any kind of analysis.
What is an error? An error is a local failure scenario that you don&#39;t currently understand - our continuous improvement process for error handling aims to move all these anomalies in the system from unknown to known.</description>
    </item>
    
  </channel>
</rss>