lemmy-synapse is a light-weight observability and monitoring stack for Lemmy servers.

Using Prometheus and Grafana, it allows the admins to visualise and query the stats of their instance. v1.0.0 comes out of the box with 3 detailed dashboards:

• Host stats (CPU, RAM, disk, network, ...)
• PostgreSQL stats (connections, locks, transations, queries, ...)
• Docker stats (container CPU, RAM, disk, network, OOM signals, ...)

It runs as Docker compose cluster alongside the Lemmy cluster and does not require any changes to it in most cases. Uninstalling lemmy-synapse is as easy as tearing down its cluster and deleting its installation directory.

Got questions/feedback? Pray drop a line:

• #lemmy-synapse:matrix.org
• !lemmy_synapse@lemmy.ml

As an instance admin, would you be interested in receiving alerts in case lemmy-meter detects your instance's health has deteriorated?

The alerts could be sent to any combination of

• a Matrix chat (private or channel)
• a Discord server
• an e-mail address

For example, you could receive an alert if the landing page hasn't been loading for the past 5 minutes.

The details of alerting levels and the conditions that'd trigger them will be ironed out later. At this stage I'd mostly would like to know if there's interest in this feature in the first place before getting to the implementation.

Follow up on https://github.com/bahmanm/lemmy-meter/issues/71

cross-posted from: https://lemmy.ml/post/6863402

Fed up w/ my ad-hoc scripts to display the targets and variables in a makefile(s), I've decided to write a reusable piece of code to do that: https://github.com/bahmanm/bmakelib/issues/81

The first step toward that would be to understand the common commenting styles. So far I have identified 4 patterns in the wild which you can find below.

Are there any style guides/conventions around this topic? Any references to well-written makefiles I can get inspiration from?

A

VAR1 = foo   ## short one-liner comment
my-target:   ## short one-liner comment 
	…

B

# longer comment which 
# may span
# several lines
VAR1 = foo

## comments can be prefixed w/ more than # 
## lorem ipsum dolor
my-target: 
	…

C

#####
# a comment block which is marked w/ several #s on
# an otherwise blank line
#####
VAR1 = foo

D

#####
#>    # heading 1
#     This is a variation to have markdown comments
#     inside makefile comments.
#
#     ## It's a made-up style!  
#     I came up w/ this style and used it to document `bmakelib`.
#     For example: https://is.gd/QtiqyA (opens github)
#<
#####
VAR1 = foo

Fed up w/ my ad-hoc scripts to display the targets and variables in a makefile(s), I've decided to write a reusable piece of code to do that: https://github.com/bahmanm/bmakelib/issues/81

The first step toward that would be to understand the common commenting styles. So far I have identified 4 patterns in the wild which you can find below.

Are there any style guides/conventions around this topic? Any references to well-written makefiles I can get inspiration from?

A

VAR1 = foo   ## short one-liner comment
my-target:   ## short one-liner comment 
	…

B

# longer comment which 
# may span
# several lines
VAR1 = foo

## comments can be prefixed w/ more than # 
## lorem ipsum dolor
my-target: 
	…

C

#####
# a comment block which is marked w/ several #s on
# an otherwise blank line
#####
VAR1 = foo

D

#####
#>    # heading 1
#     This is a variation to have markdown comments
#     inside makefile comments.
#
#     ## It's a made-up style!  
#     I came up w/ this style and used it to document `bmakelib`.
#     For example: https://is.gd/QtiqyA (opens github)
#<
#####
VAR1 = foo

cross-posted from: https://lemmy.ml/post/6856563

When writing a (GNU) Makefile, there are times when you need a particular target(s) to be run before anything else. That can be for example to check the environment, ensure variables are set or prepare a particular directory layout.

... take advantage of GNU Make's mechanism of includeing and makeing makefiles which is described in details in the manual:

When writing a (GNU) Makefile, there are times when you need a particular target(s) to be run before anything else. That can be for example to check the environment, ensure variables are set or prepare a particular directory layout.

... take advantage of GNU Make's mechanism of includeing and makeing makefiles which is described in details in the manual:

I just stumbled upon a collection of bash completions which can be quite handy: https://github.com/perlpunk/shell-completions

I tried mojo, cpan and pip completions in a sandbox and they worked like a charm!

The only question I've got is, has anyone ever done a security audit of the repository? Anyone has taken the time to look at the code? I could try auditing but I'm not even sure what to look for.

I feel quite wary of letting an unknown source access to my bash session and what I type.

I'm trying to gather requirements wrt a potential bmakelib feature linked in the post.

I'd appreciate your feedback around:

• What are the conventions you follow to document your Makefiles?
• How/where do you usually declare variables and how do you document them?

Please take a second to share your thoughts on the issue or simply reply to this post if you'd prefer 🙏

With most of the initial tasks done, I think 🌎 lemmy-meter.info is in a good place now.

I just tagged v1.0.0-beta on the repository and will be focused mainly on polishing things and fixing potential bugs in the coming days before the release of v1.0.0.

In the meantime, I'd love to know about your experience using lemmy-meter and any feedback/ideas you may have about the current version or any future versions.

Thanks in adavnce 🙏

I'm interested in registering for the tournament but I've got no clue as to where to begin? Where can I find the list of teams? How can I request to join a team?

I'd appreciate any help/hint 🙏

Cross-posted from https://lemmy.ml/post/5719058

I've been working on a simple opt-in solution, primarily for Lemmy end users like me (but also helpful for admins), to easily check the status/health of their favourite instance.

🌎 lemmy-meter.info

You can find the details of the implementation in lemmy-meter github repo.

❓ @admins: would you be interested in adding your instance to lemmy-meter?

You don't need to do anything except confirming - I'll handle the rest. It should only take a few minutes for your instance to show up in lemmy-meter.

Out of the box it will send only 4 HTTP GET requests per minute to your instance. However that is totally configurable if it sounds too much or too little.

• !lemmy_meter@lemmy.ml
• #lemmy-meter:matrix.org

💪 lemmy-meter aspires to be a one-stop webapp for Lemmy end-users (and hopefully admins), to check the status of their favourite instances.

💡 The main idea is to provide the health check information in a opt-in way that is easy consume at a first glance (simple gauges) while offering users and power users more details in case they are interested.

❌ lemmy-meter is NOT affiliated w/ the Lemmy project.

𝜷 Currently, lemmy-meter is in the beta stage while I'm working on proper documentation and mobile-friendly design.

lemmy-meter is licensed under GPLv3 and is available on github.