I'm still looking for a merging/splitting approach myself, but meanwhile this approach recommended by Kubernetes documentation seems like a sound solution: Use a sidecar container for each of your separate logs.
A "sidecar" is any docker container that you use alongside another docker container to work with it in some way. In this case for each of your ...
"Serverless" mostly just means you've got relatively simple microservices, generally just a little webapp or a single function that is automatically connected to a REST frontend. The same concepts apply as you would use for a more traditional web services: usually some mix of remote syslog and ElasticSearch writers.
Networked or remote syslog has been ...
The fire hose is a reference to an old Weird Al Yankovick movie, UHF (1989). In this movie, George Newman (portrayed by Yankovick) starts a local TV channel in the UHF band and is responsible for programming on the channel. After befriending the Station's Janitor, Stanley Spadowski, (portrayed by Michael Richards) George gives the Janitor a slot to run a ...
The idea of merging them into one stream just to split them later sounds painful. I've not had a reason to do this myself, but here's where I'd start:
When you run the docker container, create a volume such that it will be easy to view/ship logs from the host.
Use something like remote_syslog2 to ship the logs to your log collector
It feels a little less-...
This answer is more about scalability considerations - if the number of workers can be high and/or multiple of them can produce logs at high rate at the same time.
Yes, using multiple logfiles simultaneously is a good practice.
Attempting to combine into a single logfile logs from multiple workers in real time will raise problems:
using blocking mechanims ...
Both are common and comes with their own pro and cons.
It depends if you can accept loosing logs if logstash is dead and your app restart and on the other hand if you can write logs to disk and consume place there.
Those are the basic points to choose for one or the other, you may end up with more caveats in term of IO/caching/etc.
There's no 'best' ...
I like to use ELK, Elasticsearch, Logstash and Kibana with Beats.
Filebeat, that belongs to Beats series will forward the logs that read from a file to logstash.
In logstash you could tag, filter, parse and modify the log entries that are stored in Elasticsearch.
For visualizing you can use Kibana. You can create a great dashboards based on the logs with ...
As Tensibai mentioned, you can extract this info from the /proc filesystem, but in most cases you need to determine the trending yourself. There are several places which could be of interest:
Provides information about memory usage, measured in pages.
The columns are:
size (1) total program size
I think the solution comes down to a broad spectrum of approaches that ensures data protection:
Data Classification: The most efficient technical strategy is to categorise the data at the point of creation rigorously. At its core, the developers are responsible for ensuring that all logged information is assigned a category. Categorization can, for example,...
[Converting my comment to an answer]
One way to do it would be to write the logs to some external file, and then having a task after it which makes use of failed_when condition, and remove the log file, if the previous task was successful.
Something like this should help you.
- name: Run Py script
command: <>.py > <>.log
I implemented this in node.js - I don't know of a unix utility that can dynamically change grep. Here is how it works:
many-child-procs > logfile.log # in terminal 1
tail -f logfile.log | grep <expression> # in terminal 2
many-child-procs | dygrep # in terminal 1
then you ...
The question hasn't had an answer in seven months so I will promote my upvoted comment to an answer:
Finding the lifecycle of a specific message across services is known as "distributed tracing". Distributed tracing requires more than just capturing logs. OpenShift uses Kubernetes which is part of cncf.io/projects which governs opentracing.io and has one ...
I think that all you need to do is to register the output of every command you need (store it in a variable) and then simply dump the variable in a file. That way you can review it later.
- name: Dump all vars
action: template src=templates/dumpall.j2 dest=/tmp/ansible.all
Then in dumpall.j2:
Module Variables ("vars"):
I solved this by adding
to the no_log-task. This makes ansible continue to the next task, even when the task fails. Then for the next task define a debug task, which always fails and outputs the registered variable, but only runs when the previous task failed:
- name: Error output
What I do when I've a command to execute and wish to get the log only in case of failure is as follow (prefixed by a shell comamnd like /bin/sh -c '...' in case the initiator doesn't use a system call or execute the command directly without shell):
command 2&>1 > command-log.txt || cat command-log.txt
This will redirect error and standard output ...
Completely agree with RuBiCK's answer.
I handle logs of 3 servers. We keep only really important logs in the system. Rest are pushed instantly to elasticsearch database.
My view is that Using elasticsearch would be beneficial than log rotation as you can keep logs for as much time as you want. And also, you can easily make visualizations and dashboards ...
Also check the content of the log files and ask "is this relevant logging"? Sometimes, complete stack traces are logged. If this is the case, what is causing this and how to suppress it? Some apps define several log levels. If the app is running without issues, just set the log level to normal. If there are issues, change it to debug for a short moment.
If you are dealing with application logs, here are the three broad categories of information that a good log file should cover:
basic context (timestamp, log level, application name, source file name, source module/function, source line number, log message)
server context (host name, data center name unless host name has it encoded, cluster/pod info, ...
What do you mean by "it doesn't work"? I got an error suggesting that the log format wasn't correct:
Fatal error has occurred
Error occured at: src/goaccess.c - set_curses - 1394
No time format was found on your conf file.
When I edited /etc/goaccess.conf (i.e. uncommented/selected time-format, date-format and log-format) the docker logs mycontainer | ...
If all the files are there without any extension then yes you can execute the cat command with * (cat ) it will display the content of each and every files underneath this directory, but here in your output it has the zip files (.gz) too, so you need to execute 2 commands rather than single command...
cat syslog syslog.1
Hope this will helps.
Activity Logs can only able to show the resource level logs like creating a resources,deleting a resources modify the SKU of the resources etc,
Assuming from your question you are saying web app deployment from azure devops,which is more like a deployment of code to an existing webapp which will not be covered by activity logs. You need to go to that azure ...
That doc say next:
When running Tomcat on unixes, the console output is usually redirected to the file named catalina.out. The name is configurable using an environment variable. (See the startup scripts). Whatever is written to System.err/out will be caught into that file. That may include:
Uncaught exceptions printed by
Try Sparky. This is a lightweight but powerful alternative to linux crontab. It comes with nice UI to see cronjob reports and statues. You can also run tasks remotely over ssh or through docker. The typical tasks you've mentioned are covered by existing DSL ( written on Perl6 ), for example:
"Does a file, with a maximum age, exist on some network share?"
Is it a hard requirement to use only sar and sysstat? If not you might want to look at collectl or collectd. These will enable you to study memory usage over time on a per-process granularity. It's really not worth wasting your time writing your own scripts to parse /proc as the other answer suggests; this is a solved problem.