6 Replies Latest reply on Nov 21, 2019 9:30 AM by Jeff Catlin

    Send log to Kiwi vs Save in a log file


      Hi there,


                   I'm trying to figure out which way is better? Correct me if I'm wrong.

                   Currently, I want to change log level from critical to notification. I tried to avoid fill up log storage in the swtich (e.g. 3850)

      1. Kiwi: I need to change console log level in order to send notification logs to kiwi, which all the notification logs would store locally in the switch then.

      2. Log file (logging logfile logfile-name severity-level [ size bytes ]):  I can just change saving log file level to notification, and still store critical logs locally in the switch.


                 If I'm right about the concept, wouldn't it be better to store syslogs in a log file instead of sending to kiwi?


                     Thank you!!




        • Re: Send log to Kiwi vs Save in a log file

          soleilion I'm not too sure about storing logs/files on the switches, but we benefit greatly by aggregating logs, from all of our devices/servers/etc., into Kiwi. Once Kiwi receives those logs, they are stored in various flat files based on which device/type/purpose/locations/etc. they came from. Additionally, as has happened numerous times over the years, when a device goes down hard, and we cannot turn it up or log into it, while the first person is running troubles on the device, the second person is digging into the logs, alerts, etc. to find out what happened.


          While I'm not sure how your environment is configured, I know having a solid, separate, standalone syslog server works very well for us. Going to a single server, then being able to view all of the logs from all of our devices, usually works out better for us.



          Thank you,



          2 of 2 people found this helpful
          • Re: Send log to Kiwi vs Save in a log file
            Jeff Catlin

            I agree with Will on his reasoning for using Kiwi.  Kiwi also gives you a good amount of flexibility with what you can do with the data being received..  Not just flat file storage, but potentially putting it into a database for potential future reporting/searchability.  Acting as a forwarding device to send the information on to other systems for event correlation or just data ingestion.  Alerting possibilities.  Filtering options if you want to receive the noisier information but are trying to get specific bits out of the noise.  The filtering helps reduce the amount of noisy data that could be sent on for some other event correlation/monitoring solution freeing up resources for that solution to process relevant information.

            2 of 2 people found this helpful