Rotate Log Files at IST time not UTC

[abhishekvrm444 (Abhishek Verma)]

Hi,

i want to rotate the logs that i am creating using logstash file output plugin and same is happening but there is one problem arising that my system has IST(Indian standard Time) but the logtsash is rotating logs based on UTC.
That is it should rotate the logs at midnight (00:01 AM) but it is rotating the logs at 05:30 AM.

In logstash configuration, i am using below output plugin.
output {
file {
path => "/var/log/cms-%{+YYYY.MM.dd}.log"
}
}

Please help!!!

[admlko]

Hi,

I don't think this could be achieved with sprintf formatting, so you would have to use something like this:

filter {
  ruby {
    init => 'require "time"'
    code => '
      event.set("[@metadata][localtime]", Time.parse(event.get("@timestamp").to_s).localtime.strftime("%Y.%m.%d").to_s)
    '
  }
}
output {
  file {
    path => "/var/log/cms-%{[@metadata][localtime]}.log"
  }
}

[abhishekvrm444 (Abhishek Verma)]

I am able to create the directory like cms-2019.01.04.log but my question is that the logs are not rotating w.r.t Indian standard time It should create a new file at 00:01 AM midnight but it is creating the file cms-2019.01.04.log at 05:30 UTC time standard.

Please help in this !!!

[admlko]

My reply is exactly what you want. Did you even try it?
If so, what was the problem?

It is not guaranteed to work directly in your case, but I have been running very similar setup in production for 2 years for the same purpose without any problems.

[bloke]

The best way to answer this is the systems are built on UTC. The roll is at UTC 00:00 (midnight). The developers have no intention to change this design, ever. Because you are dealing with timeseries data anyway and your location is not UTC Greenwich you would just work out which sides of UTC you would need in filenames to replay certain data. If you require to give the data for a 24hr period it is just in a few different files. It is rare that you need to do this anyway, if someone needs to view the data just replay it into Elasticsearch and Kibana anyway. I dont know your exact use case but you need to understand that the systems are coded that way and they will not change it, you need to work around it with your data use cases.

[admlko]

The best way to answer this is the systems are built on UTC.

True, @timestamp is always in UTC and that is honestly the best way to deal with timestamps.

The roll is at UTC 00:00 (midnight). The developers have no intention to change this design, ever.

It is good to note that there is no built-in rotation of logs, this is just common case and easy to use what many Logstash users would want - sprintf formatting of @timestamp - because it is available in all the events.

Because you are dealing with timeseries data anyway and your location is not UTC Greenwich you would just work out which sides of UTC you would need in filenames to replay certain data. If you require to give the data for a 24hr period it is just in a few different files. It is rare that you need to do this anyway, if someone needs to view the data just replay it into Elasticsearch and Kibana anyway.

This is not a very good answer to the OP. There is a lot of cases where you would like to know exactly where a certain event is stored. For example in our case, we ingest 100+ GB every day and store them both in ES and files (for backup purposes). Maybe once or twice a month, there is a need to restore a certain set of logs from the backups. It is really a timesaver to know exactly which file we need to restore rather than restoring two or three more files.

What I am saying, is that there really is a real life use case for this, to be able to store logs to daily files in users own timezone.

I provided a ruby filter to generate a local timestamp and then use that to store the log into a file, that is the cleanest way I have been able to generate. True, it is not pretty, but it works

Please help in this !!!

Please note that this forum is based on "best effort" support from the team and us "normal users". Do not demand support if you are not willing to pay, or at least provide us with information about the issue, more than "it does not work".

[bloke]

It depends.

I got over the whole issue a long time ago. The best answer is to stick with the standard UTC in my opinion.
I have fast infrastructure and deal in very large data also so throwing a few files or more in for restoration is not an issue these days with flash arrays etc.
In the filter case you have provided with high speed ingestion it will also be a bottleneck, your doing a system call for every single event, i'd like to see the metricbeat data on that machine/s. I'd stay clear of this if its very large volumes of data.
I understand the case about getting to data more directly. But, its depends on a number of issues.

[admlko]

It depends.

Exactly.

I have fast infrastructure and deal in very large data also so throwing a few files or more in for restoration is not an issue these days with flash arrays etc.

And how about if you don't have flash arrays and modern equipment etc. "these days"
Or you are only one person with tons of other responsibilities...

In the filter case you have provided with high speed ingestion it will also be a bottleneck, your doing a system call for every single event, i'd like to see the metricbeat data on that machine/s. I'd stay clear of this if its very large volumes of data.

Of course, that's why I said that it is not ideal and is pretty ugly. But it does the job OP was asking about.

I understand the case about getting to data more directly. But, its depends on a number of issues.

Exactly, it depends on a lot of different cases. That's why I really didn't understand why would you say that it shouldn't be done.

People have tons of different sizes of setups with tons of different types of infrastructure. IMO it is not our place to say what should be done and what shouldn't, but rather suggest an answer.

I know that these type of configs have been mandatory when dealing with legacy systems where it has not been viable to do any modifications in the client side.

[bloke]

I am just offering a perspective, i never said do or don't, just a view about volumes of data and handling limits. If it works for you, use it. All the best with that.