"What's changed in the last twenty minutes?"
Aims to answer the question "what's changed in the last hour?" in a distributed system. Very useful to have when the proverbial bad things hit the proverbial ventilation hardware. It can drastically drop mean time to recovery.
changelog
provides a simple REST API to post events to, and a web interface where you can quickly see and filter events.
The basic idea is that you'll send any event that has even a remote chance of causing problems to this system. Later,
when something goes wrong, you can quickly check what's changed in the last minutes / hours.
The web interface:
Sending events is simple:
curl http://changelog.awesomecompany.com/api/events \
-X POST \
-H 'Content-Type: application/json' \
-d '{"criticality": 1, "unix_timestamp": 1395334488, "category": "misc", "description": "cli test"}'
All four JSON fields are required, and there are no other fields the server understands.
Clients implementing this logic:
Some ideas for events to send:
A public image is available at prezi/changelog.
It runs changelog
on Gunicorn with Eventlet workers, and supports SQLite, MySQL and PostgreSQL.
It's not completely production-ready out of the box, see below - you should think about at least SSL termination and authentication.
You can set any of the configuration variables described below as environment variables on the container with the same name as the
configuration variables.
To try it out with an in-container SQLite database:
sudo docker run -p 5000:5000 -it prezi/changelog
Prerequisites:
git clone https://github.com/prezi/changelog.git
cd changelog
# Install dependencies
./setup.sh
# In on shell, start the server
. virtualenv/bin/activate
python application.py
# In another shell, start the Webpack watcher
npm run watch
# When building for production, create a production frontend bundle
npm run build
changelog
uses SQLAlchemy to support a wide range of databases. The client library bindings are not included in
requirements.txt
to make setup possible in the absence of client libraries on the system. If you want to use
a database other than SQLite (you should), then you'll need to manually install the python bindings. Additional
requirements files are provided to install known good versions of the bindings:
pip install -r requirements-mysql.txt
pip install -r requirements-postgresql.txt
Variable | Description | Default |
---|---|---|
ALCHEMY_URL |
SQL Alchemy connection string. | sqlite:///changelog.db |
LISTEN_HOST |
IP address where the application will listen when started with python application.py . |
127.0.0.1 (0.0.0.0 in Docker) |
LISTEN_PORT |
Port where the application will listen when started with python application.py . |
5000 |
USE_SENTRY |
Send exceptions to Sentry? | False |
SENTRY_DSN |
Sentry DSN, used only if USE_SENTRY is True . |
None |
The default configuration values defined are in settings.py.
You can pass in any of these variables as an environment variable to the Docker container. Additional, docker-specific variables:
Variable | Description | Default |
---|---|---|
GUNICORN_WORKER_COUNT |
Number of worker processes started by Gunicorn. | 2 |
For example, to use a PostgreSQL database:
sudo docker run -d --name changelog-db postgres
sudo docker run --rm --link changelog-db:db postgres psql -h db -U postgres -c 'CREATE DATABASE changelog'
sudo docker run -it -p 5000:5000 --link changelog-db:db -e ALCHEMY_URL=postgres://postgres@db/changelog prezi/changelog
You can set the environment variable CHANGELOG_SETTINGS_PATH
to point to a python file. That file can set the values detailed
below. The application prints the final configuration at startup to make debugging this easier (not that there's anything
to debug, but configuration always needs debugging). The file pointed to by CHANGELOG_SETTINGS_PATH
can, for example,
look like this:
LISTEN_PORT = 8080
ALCHEMY_URL = 'sqlite:////opt/foo/bar/local/changelog.db'
mod_deflate
) can speed things up.Feature requests are welcome, bug reports are especially welcome, and pull requests are super welcome. Please make sure to use a feature branch in your fork. Don't look too hard for tests, there are none - not for a lack of belief in tests, but because the application is almost trivial. Please make sure you also update the README to reflect your changes. While you're there you may as well add yourself to the Credits section too :)
These tools made it possible to write changelog
in a weekend. Huge thanks.
Image gleefully copied from Android Police