• False
    • None
    • False
    • Not Selected

      Proposed title of this feature request

      Enable option for debugging Vector for troubleshooting

      What is the nature and description of the request?

      In fluentd, it was very easy to debug it. Some examples:

      • Enable debugging option (this required to move to Unmanaged)
      • For checking the content of the data log forwarded, it was easy to review the content of the buffer files and if the content of it was the expected: metadata
      • Number of buffer files on the queue indicating delays or problems to log forwarding to an specific output (probably, this can be observed in the metrics now)
      • Verify when done an specific configuration, for example, enabling json, really the content is parsed as expected and sent to the expected indice defined

      As Vector is now implemented to work in memory, we are blind from the point of view of troubleshooting and helping to make easy to understand and explain why the things are happening.

      Then, it should be desired to have an option to enable debug in an easy way for doing troubleshooting and identify possible problems and even better if this option can be in a "Managed" status.

      Also, some instructions to dump the data that Vector is holding in the memory for its revision.

      Why does the customer need this? (List the business requirements)

      Any kind of troubleshooting related to Vector and having more details about what's happening, content log forwarded, indices where the content is sent, etc.

      List any affected packages or components.

      • ClusterLogging - ClusterLogForwarder API
      • Vector

       

      NOTES:

      From grooming Dec19.  Three parts to this request:  
      1. Add the ability to set vector's log level (debug) in a Managed status
      2. Add the ability to do a "core dump" of vector data/state
      3. Add feature similar to vector tap - (delivered)

       

       

      The exact needed is what vector tap provides: https://vector.dev/guides/level-up/vector-tap-guide/ and also, https://vector.dev/guides/level-up/troubleshooting/

            [OBSDA-482] Enable option for debugging Vector for troubleshooting

            I was reviewing the pull-request from LOG-4556 and inside is not present a way to modify it in the end-user for setting tap and being able to us

            rhn-support-ocasalsa Please clarify what you mean here. My experience is anyone who is able to jump on the running container can use 'vector top'. I'm not certain what exactly there is to modify or enable for its use. Is it a separate binary not present in the production image?

            Jeffrey Cantrill added a comment - I was reviewing the pull-request from LOG-4556 and inside is not present a way to modify it in the end-user for setting tap and being able to us rhn-support-ocasalsa Please clarify what you mean here. My experience is anyone who is able to jump on the running container can use 'vector top'. I'm not certain what exactly there is to modify or enable for its use. Is it a separate binary not present in the production image?

            GitLab CEE Bot added a comment - CPaaS Service Account mentioned this issue in a merge request of openshift-logging / Log Collection Midstream on branch openshift-logging-5.8-rhel-9_ upstream _2ea2330f9798009afde64ad1eb3adbde : Updated 2 upstream sources

            GitLab CEE Bot added a comment - CPaaS Service Account mentioned this issue in a merge request of openshift-logging / Log Collection Midstream on branch openshift-logging-5.7-rhel-8_ upstream _fb7ca74910c1e8efabe58996df2ab695 : Updated US source to: 4c21e86 LOG-4556 : Enable vector API and CLI

            GitLab CEE Bot added a comment - CPaaS Service Account mentioned this issue in a merge request of openshift-logging / Log Collection Midstream on branch openshift-logging-5.8-rhel-9_ upstream _ea9378f8029c95668f7b7458e58c5929 : Updated US source to: 4c21e86 LOG-4556 : Enable vector API and CLI

            Emmanuel Kasprzyk added a comment - - edited

            > For checking the content of the data log forwarded, it was easy to review the content of the buffer files and if the content of it was the expected: metadata

            Would collecting a core dump ( like the cri-o teams sometime asks: https://access.redhat.com/solutions/5488871 ) be something engineering  consider in such a case ?

            Emmanuel Kasprzyk added a comment - - edited > For checking the content of the data log forwarded, it was easy to review the content of the buffer files and if the content of it was the expected: metadata Would collecting a core dump ( like the cri-o teams sometime asks: https://access.redhat.com/solutions/5488871 ) be something engineering  consider in such a case ?

              jamparke@redhat.com Jamie Parker
              rhn-support-ocasalsa Oscar Casal Sanchez
              Votes:
              11 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated: