How To: Save JMeterVariable values to influxdb with the sampleresults











up vote
0
down vote

favorite












I'd like to store some JMeterVariables together with the sampleResults to an influxdb using a BackendListenerClient for influxdb (I am using package rocks.nt.apm.jmeter to get the raw results).



My current test logs in for a random customer requests some random entities and logs out. Most of the results are within a range, I'd like to zoom in to certain extreme sample results, find out for which customer / requested entity these results are. We have seen in the past we can find performance issues with specific configurations this way.



I store customer and entity ID in a variable. My issue is that the JMeterVariables are not accessible from the BackendListenerClient. I looked at the sample_variables property, but this property will store the variables in the sampleEvent, which is not accessible in the BackendListener.



I could use the threadName, or sample label to store the vars, but I saw the CSVwriter can actually write the var values from the event, which is a much nicer solution.



Looking forward on your thoughts,



Best regards, Spud










share|improve this question


























    up vote
    0
    down vote

    favorite












    I'd like to store some JMeterVariables together with the sampleResults to an influxdb using a BackendListenerClient for influxdb (I am using package rocks.nt.apm.jmeter to get the raw results).



    My current test logs in for a random customer requests some random entities and logs out. Most of the results are within a range, I'd like to zoom in to certain extreme sample results, find out for which customer / requested entity these results are. We have seen in the past we can find performance issues with specific configurations this way.



    I store customer and entity ID in a variable. My issue is that the JMeterVariables are not accessible from the BackendListenerClient. I looked at the sample_variables property, but this property will store the variables in the sampleEvent, which is not accessible in the BackendListener.



    I could use the threadName, or sample label to store the vars, but I saw the CSVwriter can actually write the var values from the event, which is a much nicer solution.



    Looking forward on your thoughts,



    Best regards, Spud










    share|improve this question
























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'd like to store some JMeterVariables together with the sampleResults to an influxdb using a BackendListenerClient for influxdb (I am using package rocks.nt.apm.jmeter to get the raw results).



      My current test logs in for a random customer requests some random entities and logs out. Most of the results are within a range, I'd like to zoom in to certain extreme sample results, find out for which customer / requested entity these results are. We have seen in the past we can find performance issues with specific configurations this way.



      I store customer and entity ID in a variable. My issue is that the JMeterVariables are not accessible from the BackendListenerClient. I looked at the sample_variables property, but this property will store the variables in the sampleEvent, which is not accessible in the BackendListener.



      I could use the threadName, or sample label to store the vars, but I saw the CSVwriter can actually write the var values from the event, which is a much nicer solution.



      Looking forward on your thoughts,



      Best regards, Spud










      share|improve this question













      I'd like to store some JMeterVariables together with the sampleResults to an influxdb using a BackendListenerClient for influxdb (I am using package rocks.nt.apm.jmeter to get the raw results).



      My current test logs in for a random customer requests some random entities and logs out. Most of the results are within a range, I'd like to zoom in to certain extreme sample results, find out for which customer / requested entity these results are. We have seen in the past we can find performance issues with specific configurations this way.



      I store customer and entity ID in a variable. My issue is that the JMeterVariables are not accessible from the BackendListenerClient. I looked at the sample_variables property, but this property will store the variables in the sampleEvent, which is not accessible in the BackendListener.



      I could use the threadName, or sample label to store the vars, but I saw the CSVwriter can actually write the var values from the event, which is a much nicer solution.



      Looking forward on your thoughts,



      Best regards, Spud







      variables jmeter influxdb






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 20 at 17:03









      Spud

      33




      33
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote



          accepted










          You get it right - the Backend Listener is not customizable in terms of fine-shaping the data you're sending to Influx.
          Alas.



          However, there's a Swiss Army Knife always available in JMeter: the JSR223 components.
          The JSR223 listener, in your case.



          The InfluxDB line protocol is simple as simple could be, the HTTP/Rest libraries are
          in abundance (Apache HTTP must have been already included with standard JMeter, to my recollection, no additional jars needed) - just pick it all up, form your timeseries as you like, toss it towards your InfluxDB REST endpoint, job's done.






          share|improve this answer





















          • Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
            – Spud
            Dec 5 at 8:02













          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397992%2fhow-to-save-jmetervariable-values-to-influxdb-with-the-sampleresults%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          0
          down vote



          accepted










          You get it right - the Backend Listener is not customizable in terms of fine-shaping the data you're sending to Influx.
          Alas.



          However, there's a Swiss Army Knife always available in JMeter: the JSR223 components.
          The JSR223 listener, in your case.



          The InfluxDB line protocol is simple as simple could be, the HTTP/Rest libraries are
          in abundance (Apache HTTP must have been already included with standard JMeter, to my recollection, no additional jars needed) - just pick it all up, form your timeseries as you like, toss it towards your InfluxDB REST endpoint, job's done.






          share|improve this answer





















          • Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
            – Spud
            Dec 5 at 8:02

















          up vote
          0
          down vote



          accepted










          You get it right - the Backend Listener is not customizable in terms of fine-shaping the data you're sending to Influx.
          Alas.



          However, there's a Swiss Army Knife always available in JMeter: the JSR223 components.
          The JSR223 listener, in your case.



          The InfluxDB line protocol is simple as simple could be, the HTTP/Rest libraries are
          in abundance (Apache HTTP must have been already included with standard JMeter, to my recollection, no additional jars needed) - just pick it all up, form your timeseries as you like, toss it towards your InfluxDB REST endpoint, job's done.






          share|improve this answer





















          • Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
            – Spud
            Dec 5 at 8:02















          up vote
          0
          down vote



          accepted







          up vote
          0
          down vote



          accepted






          You get it right - the Backend Listener is not customizable in terms of fine-shaping the data you're sending to Influx.
          Alas.



          However, there's a Swiss Army Knife always available in JMeter: the JSR223 components.
          The JSR223 listener, in your case.



          The InfluxDB line protocol is simple as simple could be, the HTTP/Rest libraries are
          in abundance (Apache HTTP must have been already included with standard JMeter, to my recollection, no additional jars needed) - just pick it all up, form your timeseries as you like, toss it towards your InfluxDB REST endpoint, job's done.






          share|improve this answer












          You get it right - the Backend Listener is not customizable in terms of fine-shaping the data you're sending to Influx.
          Alas.



          However, there's a Swiss Army Knife always available in JMeter: the JSR223 components.
          The JSR223 listener, in your case.



          The InfluxDB line protocol is simple as simple could be, the HTTP/Rest libraries are
          in abundance (Apache HTTP must have been already included with standard JMeter, to my recollection, no additional jars needed) - just pick it all up, form your timeseries as you like, toss it towards your InfluxDB REST endpoint, job's done.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 30 at 22:53









          Yuri G

          75859




          75859












          • Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
            – Spud
            Dec 5 at 8:02




















          • Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
            – Spud
            Dec 5 at 8:02


















          Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
          – Spud
          Dec 5 at 8:02






          Thank you for your answer, which confirms my suspicions. I do like the suggestion to use the JSR223 listener, however will probably use it to add the thread vars in the threadname, which I think is less error prone (or do you see any issues with that approach?). I still think its odd this data is not available for the Backend Listener.
          – Spud
          Dec 5 at 8:02




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397992%2fhow-to-save-jmetervariable-values-to-influxdb-with-the-sampleresults%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python