Zoe Steinkamp
Zoe Steinkamp
My name is Zoe Steinkamp and I am a Developer Advocate for influxData. I was a front end software engineer for over 6 years before I moved into a developer advocate role. I have been with InfluxDB for over 3 years and i look forward to sharing my knowledge of the platform and databases. I enjoy learning about awesome new technologies and doing at home tech projects to help make my life as well as other peoples lives easier. My passions besides new technology include traveling and gardening.
Building an IoT App With InfluxDB, JavaScript, and Plotly.js
JSNation 2023JSNation 2023
20 min
Building an IoT App With InfluxDB, JavaScript, and Plotly.js
The Internet of Things (IoT) is increasingly driven by sensor data, with devices taking measured actions based on everything from wind speed and direction, vital body functions, illumination intensity, and temperature.
In this session we will showcase how to build a fully functional sample IoT monitoring application built with javascript and utilizing InfluxDB as its backend. With integrations to visualization libraries such as Plotly, creating automated alerts with InfluxDB as well as data downsampling.
Monitoring, Alerting, And Visualizing your Node.JS server infrastructure with Open Source tools
Node Congress 2023Node Congress 2023
31 min
Monitoring, Alerting, And Visualizing your Node.JS server infrastructure with Open Source tools
When monitoring Node.js, you can track your applications’ performance and availability by finding bottlenecks and fixing errors. You can identify issues by specifically looking at metrics like Process memory usage, Average response time, CPU usage, and more. If you add monitoring of the other components of your entire stack, you will gain a comprehensive view of what could be impacting application performance.  At that point, it can point out the problem at the code level — allowing you to track down and fix those issues before they negatively impact end user experience.  This talk will focus on the tools available from the Open Source time series database InfluxDB. It will be using the open source node.js telegraf plugin, so you can easily collect key metrics to help you get that view into your application. We will be using the Node.js Monitoring Template which is prebuilt and equipped to monitor an applications' performance and availability. All code examples will be in Javascript, and we will also go over the javascript library for those who are working in other javascript server environments, or who want to export data to their preferred visualization tools. 

How We Created the Giraffe Libraries for Time Series Data
Node Congress 2021Node Congress 2021
8 min
How We Created the Giraffe Libraries for Time Series Data
In this talk, Zoe Steinkamp will talk about Giraffe, an open source visualization library that powers data visualizations in the InfluxDB 2.0 UI. Giraffe can be used to display your data within your own app and is Fluxlang-supported! It uses algorithms to handle visualizing high volumes of time series data that InfluxDB can ingest and query.


Lightning Talks QnA, Day 1, Node Congress
Node Congress 2021Node Congress 2021
7 min
Lightning Talks QnA, Day 1, Node Congress
Video
Wow, thank you everyone. We call it lightning talks, but you were on fire. Sorry for that joke. I don't see the speakers yet. Houston, where are my speakers? Where are the lightning talk speakers? I don't see anyone. Hello. Ah, there they are. Hey, everyone. Hey. Hey. Good to see you again. We're going to go to our audience questions. Hope you're all ready. The first question I have is for Chenmei. The question is, what can I do to get the most out of distributed tracing apart from what you mentioned in the talk? Yeah, good question. I would say there are two things that you can do apart from the things that I mentioned. One is essentially tagging everything. So you need to tag your traces with things such as user ID or event ID so that it helps you get context to the traces and the logs. And the second thing that you can do is actually capture the payload. So whenever you have an HTTP request coming in, you should capture the headers and the body of the request as well as the response. Okay. Thank you. Next question is for Anthony and Austin. What if I want to connect Retool to something that is not a native integration? I can take this one. Retool supports connecting to any REST API. So this could be an internal API. It could be if there isn't a database connection for, let's say, like InfluxDB, for example, you can use the InfluxDB API as a resource. Okay. Thank you. Question for Ryan. Do you test for GraphQL vulnerabilities as well? Yeah, we do. So what happens is the scanner will hit the introspection endpoint and build the graph and runs active if it's effectively fuzzing tests against all of the various query parameters and looks for any potential vulnerabilities in your GraphQL API. Nice. Next question is for Chinmay again. What type of integration should I be looking for or at when choosing an observability product? So I would kind of categorize integrations into four parts, alerts, environments, and frameworks as well as add-ons. So you need to see what kind of alert platforms you support. So for example, Slack or Jira, then you need to see the environments, AWS, Azure, then you need to see the frameworks such as Node.js or Python, and then finally add-ons such as debugging software such as Sentry or something like that. So all these four should be in your environment and you should look at those for selecting your observability solution. Okay, thank you. Another question for Anthony and Austin again. How do I set up Retool on prem? Yeah, that's a great question. So whenever you want to deploy Retool on prem, we have a Docker image you can pull down. Essentially Retool, there's like a stateless Retool container and with a Postgres that backs up any data about your users, permissions and things like that. So it's just a matter of running a few commands on a Docker image and you can pull it with Docker Compose, Kubernetes, Helm, etc. It's all prepared, download, install, and go. Exactly. Ryan, does StackHawk run tests against microservices also? It does. That's actually our recommended way of testing. So traditional application security testing is running against the application in production, which A, means any vulnerabilities that are found or live in production. And B, then if you find something, you have to go figure out where it lives. Scans take a long time. So it's just kind of this outdated model. So with StackHawk, it runs in CICD and you run against the individual underlying services, APIs, smallest units that you can. And it makes for really fast tests. And then if there is a finding, it's really easy to hone in on what needs to be fixed. Nice. Another question for you, Ryan. How would I fix a vulnerability if it was surfaced in StackHawk? Yeah. So when you have a finding within the StackHawk UI and it shows the overview of what that security bug is, if you're not familiar with it, links out to cheat sheets of how to fix it. But then within StackHawk, you have the request that was sent into the application, the response that received back with highlighted evidence of why it's a security bug. And then there's a curl command generator to go recreate that exact same request. So you can step through your code and debug what's going wrong. Okay, cool. That's nice. That's all the questions we have right now from our audience. So I guess we can wrap up for now. I want to thank you all for joining us and hope to see you again real soon in real life. Bye-bye.