Servers inside container

[crazynds]

Pulse Version

1.0^@beta

Laravel Version

10.39

PHP Version

8.3

Livewire Version

3.0.2

Database Driver & Version

Postgresql 15

Description

I'm integrating laravel pulse in my docker enviroment in production, and I setted all container to run the command php artisan pulse:check in background, but as result in my dashboard is showing like this.

All the containers are running in the same machine, so all of then show the same information. I'm thinking if has a way to show only the CPU and Memory of that container? Even if i has to pass a flag to the command like ```php artisan pulse:check --container" this will work for me.

I have this setup because I run the workers in separeted containers, so i can scale then in my application.

Steps To Reproduce

Run this command at every container of the aplication in the same machine.

[jessarcher]

Hi @crazynds,

Do you know of a reliable way to determine the stats?

docker stats gives the CPU and memory information, but that command can only be run from the host, not inside the containers.

There are various files within the containers' /sys/fs/cgroup directory that can be read from within the container, but I can't reliably determine which files to read. On my machine, /sys/fs/cgroup/memory.current shows memory usage, but searching online most people talk about /sys/fs/cgroup/memory/memory.usage_in_bytes, which doesn't exist on my machine.

There's documentation on this at https://docs.docker.com/config/containers/runmetrics/, however the CPU stats don't work for me - I don't have a /sys/fs/cgroup/cpuacct directory.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[jessarcher]

I'm also wondering what the "best practice" would be for collecting this information. It's my understanding that Docker isn't intended to have multiple processes per container. I.e. no pulse:check command running inside every container in addition to the "main" process. Obviously, it's possible with tools like supervisor, but I think that's more of a workaround, especially in production containers.

Running a single pulse:check command on the host machine would make it easy to get the stats automatically for all containers via docker stats, but that requires having PHP installed on the host machine, which I don't think is a good practice.

Ideally, the pulse:check command would run in a dedicated container. However, I'm unsure whether it's possible to get stats from the other containers without giving it too many privileges.

If there isn't a good and simple way of achieving this, it might be better to create it as a package.

[crazynds]

There are various files within the containers' /sys/fs/cgroup directory that can be read from within the container, but I can't reliably determine which files to read. On my machine, /sys/fs/cgroup/memory.current shows memory usage, but searching online most people talk about /sys/fs/cgroup/memory/memory.usage_in_bytes, which doesn't exist on my machine.

In my search in the docker documentation, I saw that the use of memory in memory.current is standardized in cgroupv2. Since docker supports cgroup v2 since version 20.10.
And for CPU, we can use cpu.stat.

There's documentation on this at https://docs.docker.com/config/containers/runmetrics/, however the CPU stats don't work for me - I don't have a /sys/fs/cgroup/cpuacct directory.

I couldn't find either in my docker the cpuacct in any directory of my docker containers, but in the docker documentation they mention:

So I belive it's just outdated documentation, but in my tests the containers are working with all the cgroupv2 interface files from kernel.org documentation.

I'm also wondering what the "best practice" would be for collecting this information. It's my understanding that Docker isn't intended to have multiple processes per container. I.e. no pulse:check command running inside every container in addition to the "main" process. Obviously, it's possible with tools like supervisor, but I think that's more of a workaround, especially in production containers.

Currently I have no idea how to run pulse:check without it being a secondary process. But this way it should work fine. Maybe I could add this call in the health check, with a command like pulse:check --once or so.

If you need I could make some draft getting the load information from container when the tag --docker or --container is provided, and make a pull request to show the code.

Our use case

Currently in our infrastructure we use grafana + prometheus to monitor the load on each container. We are studying a way to integrate the pulse library in our project, and centralize our information only on pulse, primarly because pulse get a lot of important informations about the system. We could use the pulse without getting the load information from the container, but I think this could be a great addition to the lib.

We have multiple containers running acros some servers in our network, so getting the information about the load of the server is not much useful to manage the containers.

[crazynds]

@jessarcher If you need anything else for this issue you can tell me.

[jessarcher]

Hi @crazynds, I'm open to a PR that uses the metrics from cgroupv2. I'm not sure whether it should be automatically used when it's running inside a Docker container or whether it should be configurable. I guess some folks might still prefer system stats rather than container stats so it should probably be configurable.

I'm not sure a --docker option makes sense though, as the pulse:check command only fires a generic event for recorders to listen to and doesn't have recorder-specific concerns. My gut feel is that it should be a config file option for the recorder.

We added support for --once in #314 which sounds like it might be helpful if you wanted to run this via the health check!

[timacdonald]

Hey, folks, I've got an alternative proposal that I think will scale better for Pulse: #339

I'll close this one and we can keep an eye on that PR. If we don't move forward with the PR we can look at adding more first-party detection strategies.