<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Logging on Caktus Group</title><link>https://www.caktusgroup.com/tags/logging/</link><description>Recent content in Logging on Caktus Group</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 20 Jun 2019 12:00:00 +0000</lastBuildDate><atom:link href="https://www.caktusgroup.com/tags/logging/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Set Up a Centralized Log Server with rsyslog</title><link>https://www.caktusgroup.com/blog/2019/06/20/how-to-set-up-centralized-log-server-rsyslog/</link><pubDate>Thu, 20 Jun 2019 12:00:00 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2019/06/20/how-to-set-up-centralized-log-server-rsyslog/</guid><description>&lt;p>For many years, we've been running an ELK (Elasticsearch, Logstash,
Kibana) stack for centralized logging. We have a specific project that
requires on-premise infrastructure, so sending logs off-site to a hosted
solution was not an option. Over time, however, the maintenance
requirements of this self-maintained ELK stack were staggering.
Filebeat, for example, filled up all the disks on all the servers in a
matter of hours, not once, but twice (and for different reasons) when it
could not reach its Logstash/Elasticsearch endpoint. Metricbeat suffered
from a similar issue: It used far too much disk space relative to the
value provided in its Elasticsearch indices. And while provisioning a
self-hosted ELK stack has gotten easier over the years, it's still a
lengthy process, which requires extra care anytime an upgrade is needed.
Are these problems solvable? Yes. But for our needs, a simpler solution
was needed.&lt;/p></description></item><item><title>Django Logging Configuration: How the Default Settings Interfere with Yours</title><link>https://www.caktusgroup.com/blog/2015/01/27/Django-Logging-Configuration-logging_config-default-settings-logger/</link><pubDate>Tue, 27 Jan 2015 16:04:04 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2015/01/27/Django-Logging-Configuration-logging_config-default-settings-logger/</guid><description>&lt;p>My colleague &lt;a href="http://www.caktusgroup.com/about/vinod-kurup/" target="_blank" rel="noopener noreferrer">Vinod&lt;/a> recently found the answer on Stack Overflow to something that&amp;rsquo;s been bugging me for a long time - why do my Django logging configurations so often not do what I think they should?&lt;/p></description></item><item><title>Central logging in Django with Graylog2 and graypy</title><link>https://www.caktusgroup.com/blog/2013/09/18/central-logging-django-graylog2-and-graypy/</link><pubDate>Wed, 18 Sep 2013 14:00:12 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2013/09/18/central-logging-django-graylog2-and-graypy/</guid><description>&lt;p>Django's &lt;a href="https://docs.djangoproject.com/en/1.5/topics/logging/" target="_blank" rel="noopener noreferrer">logging
configuration&lt;/a>
facilities, which arrived in version 1.3, have greatly eased (and
standardized) the process of configuring logging for Django projects.
When building complex and interactive web applications at Caktus, we've
found that detailed (and properly configured!) logs are key to
successful and efficient debugging. Another step in that process &amp;mdash;
which can be particularly useful in environments where you have multiple
web servers &amp;mdash; is setting up a centralized logging server to receive
all your logs and make them available through an easily accessible web
interface. There are a number useful tools to do this, but one we've
found that works quite well is &lt;a href="http://graylog2.org/" target="_blank" rel="noopener noreferrer">Graylog2&lt;/a>.
Installing and configuring Graylog2 is outside the scope of this post,
but there are plenty of tutorials on how to do so accessible through
your search engine of choice.&lt;/p></description></item><item><title>Remote logging with Python logging and Django</title><link>https://www.caktusgroup.com/blog/2009/06/09/remote-logging-with-python-logging-and-django/</link><pubDate>Tue, 09 Jun 2009 12:47:10 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2009/06/09/remote-logging-with-python-logging-and-django/</guid><description>&lt;p>As part of my work on &lt;a href="http://www.everywatt.com/" target="_blank" rel="noopener noreferrer">EveryWatt&lt;/a>, our
fledgling energy monitoring web site, I needed a way to consolidate log
messages from all the data loggers we have running in a single place. If
you're not familiar with it, Python's &lt;a href="http://docs.python.org/library/logging.html" target="_blank" rel="noopener noreferrer">logging
module&lt;/a> is good stuff and
worth checking out. We already used it for logging to files locally, and
the module defines an
&lt;a href="http://docs.python.org/library/logging.html#logging.handlers.HTTPHandler" target="_blank" rel="noopener noreferrer">HTTPHandler&lt;/a>
that can deliver log messages to a remote server via HTTP.&lt;/p></description></item></channel></rss>