Lightweight monitoring compatible with the Sentry protocol, GlitchTip

Foreword

The previous article discussed restarting Sentry

Because the process was so cumbersome, I once thought about giving up Sentry and switching to another, more lightweight open-source monitoring system

And just like that, I found two others

• https://glitchtip.com/
• https://www.highlight.io/

This time, let's try out this GlitchTIP

After using it, I realized it's also developed with Django, and it's compatible with the Sentry protocol. Even the SDK uses Sentry's...

It's essentially a lightweight drop-in replacement for Sentry

Environment Preparation

Compared to Sentry, GlitchTip is extremely lightweight, using only Redis and Celery.

Log data is stored in PostgreSQL.

This makes things much easier—deployment is significantly simpler compared to heavyweight frameworks like Sentry.

The deployment described in this article is based on a modified version of the official docker-compose configuration.

PostgreSQL

First, prepare the database

The official compose file includes a database, but since I already have a database on my server, I don't want to create additional redundant containers.

services:
  db:
    image: postgres
    container_name: pgsql
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=数据库管理员密码
    expose:
      - 5432
    ports:
      - 5432:5432
    volumes:
      - ./data:/var/lib/postgresql/data
    networks:
      - default

networks:
  default:
    name: pgsql

After starting pgsql, create the database and user used by GlitchTip.

-- Create user: Use the CREATE ROLE or CREATE USER command to create a new user.
CREATE USER glitchtip WITH PASSWORD 'glitchtip用户密码';

-- Grant privileges: To ensure the glitchtip user can only access the glitchtip database, set appropriate permissions.
GRANT ALL PRIVILEGES ON DATABASE glitchtip TO glitchtip;

-- Grant permission to create tables in the public schema
GRANT CREATE ON SCHEMA public TO glitchtip;
-- Grant usage permission in the public schema
GRANT USAGE ON SCHEMA public TO glitchtip;

The database setup is now complete.

Extension: Adminer

If you want to manage the database via a web interface, you can start an Adminer service.

services:
  adminer:
    image: adminer
    container_name: adminer
    restart: always
    networks:
      - swag
      - pgsql
      - mysql

networks:
  swag:
    name: swag
    external: true
  pgsql:
    name: pgsql
    external: true
  mysql:
    name: mysql
    external: true

After starting the service, simply configure a reverse proxy for port 8000 in SWAG.

Redis

Redis is relatively lightweight, so it's recommended to use the one provided by GlitchTip instead of a shared Redis instance.

Unless you're building a cluster.

Installing GlitchTip

I modified the official Compose configuration provided.

A few things to note:

• The email address and password need to be escaped using urllib.parse.quote(). I'm still using a corporate email here, but trying both the smtp:// and smtps:// prefixes didn't work for sending.
• I removed the top-level volumes from the official setup and placed the data in the current directory for easier management. For large amounts of data, you might consider using OSS.
• We are using the PostgreSQL database we deployed earlier, instead of spinning up another one in the Compose file.

x-environment: &default-environment
  DATABASE_URL: postgres://glitchtip:glitchtip用户密码@pgsql:5432/glitchtip
  SECRET_KEY: 建议32位随机密码 # 可以使用命令生成 openssl rand -hex 32
  PORT: 8000
  EMAIL_URL: smtp://邮箱地址:邮箱密码@smtp.exmail.qq.com:465
  GLITCHTIP_DOMAIN: https://glitchtip.example.com
  DEFAULT_FROM_EMAIL: 邮箱地址
  CELERY_WORKER_AUTOSCALE: "1,3"
  CELERY_WORKER_MAX_TASKS_PER_CHILD: "10000"

x-depends_on: &default-depends_on
  - redis

services:
  redis:
    image: redis
    restart: unless-stopped
    networks:
      - default
  
  web:
    image: glitchtip/glitchtip
    depends_on: *default-depends_on
    ports:
      - "8000:8000"
    environment: *default-environment
    restart: unless-stopped
    volumes:
      - ./uploads:/code/uploads
    networks:
      - default
      - pgsql
      - swag
  
  worker:
    image: glitchtip/glitchtip
    command: ./bin/run-celery-with-beat.sh
    depends_on: *default-depends_on
    environment: *default-environment
    restart: unless-stopped
    volumes:
      - ./uploads:/code/uploads
    networks:
      - default
      - pgsql
  
  migrate:
    image: glitchtip/glitchtip
    depends_on: *default-depends_on
    command: "./manage.py migrate"
    environment: *default-environment
    networks:
      - pgsql
      - default

networks:
  default:
    name: glitchtip
  swag:
    name: swag
    external: true
  pgsql:
    name: pgsql
    external: true

Then simply start it up.

After the first startup, a migration is required. The worker will throw errors during this time, which is normal. Just wait for the migration to complete.

After logging in, register and create a new organization, and you can start using it normally.

Usage in Code

Using GlitchTip Only

If you're solely using GlitchTip, you can treat it just like Sentry.

import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration

sentry_sdk.init(
    dsn="YOUR-GLITCHTIP-DSN-HERE",
    integrations=[DjangoIntegration()],
    auto_session_tracking=False,
    traces_sample_rate=0.01,
    release="1.0.0",
    environment="production",
)

That's all there is to it.

Using with Sentry

PS: Why would you need to use it with Sentry?

sentry_sdk does not natively support initializing multiple instances simultaneously.

Therefore, we implement this functionality with some additional logic.

class GlitchtipSentrySdk:
    def __init__(self, dsn):
        self.client = sentry_sdk.Hub(sentry_sdk.Client(dsn))

    def capture_exception(self, exc):
        with self.client:
            sentry_sdk.capture_exception(exc)

glitchtip = GlitchtipSentrySdk('https://balabalaba@glitchtip.example.com/1')

That's it.

Summary

After a simple test, GlitchTip really feels much more basic.

However, it still has the most fundamental error collection capabilities.

If server performance is insufficient, it can serve as a decent budget-friendly alternative (平替) to Sentry.

There's also Highlight that I haven't deployed yet; the configuration there is a bit complex.