New answers tagged syslog
The issue was that I used tcp() and udp() source driver [BSD format] instead of syslog() [IETF format]. It's working now.
As mentioned in another thread: "I had something similar, it sounds like you havent setup ACL's to allow the logstash user to view that log file. Use 'setfacl -m u:logstash-:r-x /var/log' for example, and then test by editing /etc/passwd and giving the logstash user a shell temporarily. Then, su - logstash, and try and cd or cat that file. If it works, ...
If you are using a text-editor to view the log files, that could be the cause; the "^@" characters may indicate that a line is too long (eg: in vim, turn on wrapping) The encoding is mismatched; either use a different text-editor to view the file, or change the encoding used by syslog.
You could set up a separate index in Splunk for the firewall data. Configure the firewall data to go in to the firewall index. Add a role for the managed services users. Give that role access to the firewall index only.
Take a look at elasticsearch + logstash + kibana Logstash can parse your log files and extract information from them using filters. It can store them in Elasticsearch, which you can query via Kibana. Have a look at the videos on their site to get a feel about what it can do.
Your first option could be done via loghost (basically your option 2) You can send your syslog message via udp to $logserver . Then you would split the logs there based on server and have the "exact" timestamps of the logs you did send. The renaming of logs would be not necessary on the nginx servers, other than the usual logrotate you most likely need with ...
The "rsyslogd was HUPed" indicates that the rsyslog process restarted, and it's the last message because presumably it wasn't working before, and rsyslog is the process that would normally leave messages in the log. So when it restarts, the messages restart. This is possibly related to a known Ubuntu bug, you can read more about it here ...
You can use: ErrorLog "| tee -a /var/log/httpd/error_log | /usr/bin/logger -t httpd -i -p local4.error" to do what you are after.
Yes, most likely by executing: dig ns problematic-domain.com @127.0.0.1 dig aaaa problematic-domain.com @127.0.0.1 or host -t ns problematic-domain.com 127.0.0.1 host -t aaaa problematic-domain.com 127.0.0.1 From what I see problem with that domain comes from the fact that two nameservers responsible for that domain have the same ip as the record in ...
Top 50 recent answers are included