Influx

influx

Partnership to provide decentralized computing resources, enhancing platform scalability, security and high availability for distributed services.
Mizzle Partners with InFlux Technologies to Power DePIN Platform with Decentralized Cloud Infrastructure and Advanced Computing Resources InFlux Technologies (Flux), a leading global decentralized technology company specializing in cloud infrastructure, artificial intelligence, and decentralized cloud computing services, today announced a partnership with Mizzle, a pioneering decentralized physical infrastructure network (DePIN) platform. Under the partnership agreement, Flux will provide decentralized computing resources including CPU, GPU, storage and network capacity as required by Mizzle for its platform operations. This includes support for distributed applications and services, ensuring high availability, scalability and security. The agreement also includes monitoring and management of Mizzle’s infrastructure to ensure optimal performance along with maintenance and upgrades of the infrastructure as needed. Mizzle will work toward an estimated spend of $500,000-plus per year post-launch, with an estimated launch of January 2025. “This partnership represents a key step in our commitment to delivering decentralized computing solutions at scale. By supplying Mizzle with essential resources, we are ensuring the platform’s ability to maintain high availability, scalability, and security. This agreement highlights the growing demand for decentralized infrastructure and demonstrates its practical applications in supporting distributed services," said InFlux Technologies CEO and Co-founder, Daniel Keller. Mizzle is a hyper-efficient CI/CD with no-code development operations which simplifies server management allowing teams to innovate and scale without operational hurdles. Its confidential computing experience carries unmatched security with TEEs, eBPF and decentralized cloud compute, keeping data and operations fully protected. Mizzle has advanced storage and benefits from decentralized cloud storage enhanced with zero knowledge proofs and fully homomorphic encryption. The company is quantum ready with edge computing, is IoT-ready and committed to green computing. Flux ensures a minimum uptime of 99.99% of decentralized infrastructure services, barring any outages or maintenance windows and offers technical support to integrate and manage the compute resources. Flux offers data security and compliance and complies with all relevant data and security regulations, ensuring the infrastructure is designed to meet regulation standards. “We are excited to partner with InFlux Technologies, taking a key step toward advancing decentralized cloud solutions. By combining Mizzle's technology with Flux’s expertise, we will drive greater value for enterprises and governments worldwide. Together, we are shaping the future of decentralized applications and empowering innovation across the ecosystem,” said Founder of Mizzle Arjun Mishra. About Mizzle Mizzle is a DePIN platform designed to empower developers with no-code DevOps. We enable atomic and horizontal scaling of compute and storage, ensuring unparalleled flexibility and performance. Our platform combines advanced AI-driven infrastructure management with trusted execution environments (TEEs), leveraging eBPF technology for real-time protection and monitoring. We also incorporate  state-of-the-art cryptographic techniques, including Fully Homomorphic Encryption and Zero-Knowledge Proofs, to guarantee maximum data privacy and security. As we move into the quantum era, with a strong commitment to Green computing (ESG), Mizzle is your trusted partner for scalable, secure, and efficient decentralized infrastructure. For more information, visit the company’s website at www.mizzle.io. About InFlux Technologies InFlux Technologies (Flux) is powering a decentralized Web3 cloud infrastructure composed of user-operated, scalable, and globally distributed computational nodes. Flux provides the critical, high-availability infrastructure for the New Internet. The Flux service offers a  fully decentralized alternative to some of the world’s largest cloud infrastructure providers while offering competitive pricing. Flux is committed to developing disruptive solutions that empower individuals and businesses in the blockchain industry, emerging technologies like AI, and the broader technology space worldwide. For more information, visit the company’s website at www.runonflux.com. This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. Partnership to provide decentralized computing resources, enhancing platform scalability, security and high availability for distributed services. Mizzle Partners with InFlux Technologies to Power DePIN Platform with Decentralized Cloud Infrastructure and Advanced Computing Resources Partnership to provide decentralized computing resources, enhancing platform scalability, security and high availability for distributed services. Mizzle Partners with InFlux Technologies to Power DePIN Platform with Decentralized Cloud Infrastructure and Advanced Computing Resources InFlux Technologies (Flux), a leading global decentralized technology company specializing in cloud infrastructure, artificial intelligence, and decentralized cloud computing services, today announced a partnership with Mizzle , a pioneering decentralized physical infrastructure network (DePIN) platform. InFlux Technologies InFlux Technologies Mizzle Mizzle Under the partnership agreement, Flux will provide decentralized computing resources including CPU, GPU, storage and network capacity as required by Mizzle for its platform operations. This includes support for distributed applications and services, ensuring high availability, scalability and security. The agreement also includes monitoring and management of Mizzle’s infrastructure to ensure optimal performance along with maintenance and upgrades of the infrastructure as needed. Mizzle will work toward an estimated spend of $500,000-plus per year post-launch, with an estimated launch of January 2025. “This partnership represents a key step in our commitment to delivering decentralized computing solutions at scale. By supplying Mizzle with essential resources, we are ensuring the platform’s ability to maintain high availability, scalability, and security. This agreement highlights the growing demand for decentralized infrastructure and demonstrates its practical applications in supporting distributed services," said InFlux Technologies CEO and Co-founder, Daniel Keller. Mizzle is a hyper-efficient CI/CD with no-code development operations which simplifies server management allowing teams to innovate and scale without operational hurdles. Its confidential computing experience carries unmatched security with TEEs, eBPF and decentralized cloud compute, keeping data and operations fully protected. Mizzle has advanced storage and benefits from decentralized cloud storage enhanced with zero knowledge proofs and fully homomorphic encryption. The company is quantum ready with edge computing, is IoT-ready and committed to green computing. Flux ensures a minimum uptime of 99.99% of decentralized infrastructure services, barring any outages or maintenance windows and offers technical support to integrate and manage the compute resources. Flux offers data security and compliance and complies with all relevant data and security regulations, ensuring the infrastructure is designed to meet regulation standards. “We are excited to partner with InFlux Technologies, taking a key step toward advancing decentralized cloud solutions. By combining Mizzle's technology with Flux’s expertise, we will drive greater value for enterprises and governments worldwide. Together, we are shaping the future of decentralized applications and empowering innovation across the ecosystem,” said Founder of Mizzle Arjun Mishra. About Mizzle About Mizzle Mizzle is a DePIN platform designed to empower developers with no-code DevOps. We enable atomic and horizontal scaling of compute and storage, ensuring unparalleled flexibility and performance. Our platform combines advanced AI-driven infrastructure management with trusted execution environments (TEEs), leveraging eBPF technology for real-time protection and monitoring. We also incorporate  state-of-the-art cryptographic techniques, including Fully Homomorphic Encryption and Zero-Knowledge Proofs, to guarantee maximum data privacy and security. As we move into the quantum era, with a strong commitment to Green computing (ESG), Mizzle is your trusted partner for scalable, secure, and efficient decentralized infrastructure. For more information, visit the company’s website at www.mizzle.io . www.mizzle.io www.mizzle.io About InFlux Technologies About InFlux Technologies InFlux Technologies (Flux) is powering a decentralized Web3 cloud infrastructure composed of user-operated, scalable, and globally distributed computational nodes. Flux provides the critical, high-availability infrastructure for the New Internet. The Flux service offers a  fully decentralized alternative to some of the world’s largest cloud infrastructure providers while offering competitive pricing. Flux is committed to developing disruptive solutions that empower individuals and businesses in the blockchain industry, emerging technologies like AI, and the broader technology space worldwide. For more information, visit the company’s website at www.runonflux.com . www.runonflux.com www.runonflux.com This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. Business Blogging

Mizzle Partners with InFlux Technologies to Power DePIN Platform

Mizzle werk saam met InFlux Technologies om DePIN-platform aan te dryf

Mizzle se asocia con InFlux Technologies para impulsar la plataforma DePIN

Mizzle kumppanuus InFlux Technologies Power DePIN Platform

Mizzle partnerek az InFlux Technologies segítségével a Power DePIN platformon

Mizzle が InFlux Technologies と提携して DePIN プラットフォームを強化

Mizzle, DePIN 플랫폼 구동을 위해 InFlux Technologies와 협력

DePIN платформасын иштетүү үчүн InFlux Technologies менен Mizzle өнөктөштөрү

Mizzle dia miara-miasa amin'ny InFlux Technologies amin'ny Power DePIN Platform

Mizzle партнери со InFlux Technologies to Power DePIN платформата

Mizzle Partners neInFlux Technologies kune Power DePIN Platform

Mizzle samarbetar med InFlux Technologies för att driva DePIN-plattformen

ሚዝል ምስ ኢንፍሉክስ ቴክኖሎጂስ ብምትሕብባር ንዲፒን ፕላትፎርም ሓይሊ ይህብ

1. What do you currently do and what’s your favorite part about it? As the CEO of InFlux Technologies (Flux), I lead the world's largest decentralized compute network, with over 13,000 systems of administrators and enterprise nodes spanning 81 countries. What excites me most is working with disruptive technologies that are transforming industries in real time. I’m passionate about staying at the forefront of innovation, helping to foster growth, and supporting the development of groundbreaking technologies that have the potential to change how we live and work. 2. How did you get started with your Tech Career? I started my tech journey in the healthcare and nonprofit sectors, where resources were limited, and I often had to innovate with minimal tools due to the high costs of technology. That experience taught me how to create impactful solutions with limited resources, a mindset I’ve carried throughout my career. It’s this focus on accessible, transformative technology that ultimately led me to what I do today with InFlux Technologies, where we are building solutions that empower people globally. 3. If Utopia were a color what color do you think it’d be and why? I might be a bit biased, but I truly believe that Flux blue represents the ideal color for the future! What sets our product apart is that it’s designed with the everyday person in mind. Our motto, "for the people, by the people," drives everything we do. As we continue to develop this technology, we’re focused on making sure it evolves into the next version of the internet—one that is truly accessible and beneficial for everyone 4. If everything about HackerNoon changed drastically, what is one detail you’d like to keep exactly the same?  OR What’s your favorite thing to do with HackerNoon and why? I wouldn’t change a thing! It’s awesome to dive into emerging technologies before they hit mainstream adoption. Focusing on the founders and the people behind the products is such a forward-thinking approach. Honestly, I’d keep it just the way it is—just make sure that the great interactions with developers and the team stay as engaging as ever on the blog! 5. Tell us more about the things you write/make/manage/build! We’re building the technology delivery framework for the next evolution of the internet—which is pretty wild when you think about it. The internet has transformed drastically since its inception, and the original vision of it being a town square is long gone. Creating a system that doesn’t rely on massive data centers or big tech providers is a game-changer. It’s the key to decentralizing power and shaping the future of the internet and technology as we know it. 6. What’s your favorite thing about the internet? The internet used to be accessible and relatively unrestricted for everyone, but that’s no longer the case as we witness increasing deplatforming and censorship every day. As a cypherpunk at heart, I strongly believe that freedom of speech and code is essential. That’s why I’m drawn toward a decentralized, community-driven platform, rather than relying on large data providers who have become the disruptors. 7. It’s an apocalypse of ‘walking dead’ proportions and you can only own a singular piece of technology, what would it be? One of those really old clickety keyboards—you could knock a few zombies out with that thing! 8. What is your least favorite thing about the internet? My least favorite thing is how the internet is now dominated by a few major players like Google and Microsoft. I believe it’s time to return to our roots and start developing the next iteration of the internet—one where individuals can control and monetize their own data, rather than being products of these tech giants. 9. If you were given $10 million to invest in something today what would you invest in and why? InFlux Technologies / Flux, naturally. 10. What’s something you’re currently learning or excited to learn? Recently with the release of our FluxAI, I’m starting to dig down the rabbit hole of truly what AI can do long-term and strategically. AI frightens many, but it is an unbelievable opportunity for all of us. Suspending more time researching how decentralization and AI can work together is absolutely one of the coolest things I've ever done. 11. Would you rather travel 10 years into the past or 10 years into the future? Give reasons for your answer. What if I tell you I don’t want to do either one of those things. I am very content with being where I’m at right now and watching how things are materializing. Going back 10 years would make you start over again. Rolling for 10 years, you would miss lots of opportunities so maybe I’m just old-fashioned but I like right where we’re at today! 12. How do you feel about AI? I’m not someone who views AI with doom and gloom. Instead, I believe it represents an unbelievable opportunity to expand many technologies and also the human race. I don’t believe in dystopian scenarios or that the Eagle Borg is going to take over and terminate all of us. I think the opportunities far outweigh the risks. But with that, there needs to be a decentralized open source and unfettered version of AI, that’s what InFlux Technologies is doing. 1. What do you currently do and what’s your favorite part about it? As the CEO of InFlux Technologies (Flux), I lead the world's largest decentralized compute network, with over 13,000 systems of administrators and enterprise nodes spanning 81 countries. What excites me most is working with disruptive technologies that are transforming industries in real time. I’m passionate about staying at the forefront of innovation, helping to foster growth, and supporting the development of groundbreaking technologies that have the potential to change how we live and work. 2. How did you get started with your Tech Career? I started my tech journey in the healthcare and nonprofit sectors, where resources were limited, and I often had to innovate with minimal tools due to the high costs of technology. That experience taught me how to create impactful solutions with limited resources, a mindset I’ve carried throughout my career. It’s this focus on accessible, transformative technology that ultimately led me to what I do today with InFlux Technologies, where we are building solutions that empower people globally. 3. If Utopia were a color what color do you think it’d be and why? I might be a bit biased, but I truly believe that Flux blue represents the ideal color for the future! What sets our product apart is that it’s designed with the everyday person in mind. Our motto, "for the people, by the people," drives everything we do. As we continue to develop this technology, we’re focused on making sure it evolves into the next version of the internet—one that is truly accessible and beneficial for everyone 4. If everything about HackerNoon changed drastically, what is one detail you’d like to keep exactly the same?  OR What’s your favorite thing to do with HackerNoon and why? I wouldn’t change a thing! It’s awesome to dive into emerging technologies before they hit mainstream adoption. Focusing on the founders and the people behind the products is such a forward-thinking approach. Honestly, I’d keep it just the way it is—just make sure that the great interactions with developers and the team stay as engaging as ever on the blog! 5. Tell us more about the things you write/make/manage/build! We’re building the technology delivery framework for the next evolution of the internet—which is pretty wild when you think about it. The internet has transformed drastically since its inception, and the original vision of it being a town square is long gone. Creating a system that doesn’t rely on massive data centers or big tech providers is a game-changer. It’s the key to decentralizing power and shaping the future of the internet and technology as we know it. 6. What’s your favorite thing about the internet? The internet used to be accessible and relatively unrestricted for everyone, but that’s no longer the case as we witness increasing deplatforming and censorship every day. As a cypherpunk at heart, I strongly believe that freedom of speech and code is essential. That’s why I’m drawn toward a decentralized, community-driven platform, rather than relying on large data providers who have become the disruptors. 7. It’s an apocalypse of ‘walking dead’ proportions and you can only own a singular piece of technology, what would it be? One of those really old clickety keyboards—you could knock a few zombies out with that thing! 8. What is your least favorite thing about the internet? My least favorite thing is how the internet is now dominated by a few major players like Google and Microsoft. I believe it’s time to return to our roots and start developing the next iteration of the internet—one where individuals can control and monetize their own data, rather than being products of these tech giants. 9. If you were given $10 million to invest in something today what would you invest in and why? InFlux Technologies / Flux, naturally. 10. What’s something you’re currently learning or excited to learn? Recently with the release of our FluxAI, I’m starting to dig down the rabbit hole of truly what AI can do long-term and strategically. AI frightens many, but it is an unbelievable opportunity for all of us. Suspending more time researching how decentralization and AI can work together is absolutely one of the coolest things I've ever done. 11. Would you rather travel 10 years into the past or 10 years into the future? Give reasons for your answer. What if I tell you I don’t want to do either one of those things. I am very content with being where I’m at right now and watching how things are materializing. Going back 10 years would make you start over again. Rolling for 10 years, you would miss lots of opportunities so maybe I’m just old-fashioned but I like right where we’re at today! 12. How do you feel about AI? I’m not someone who views AI with doom and gloom. Instead, I believe it represents an unbelievable opportunity to expand many technologies and also the human race. I don’t believe in dystopian scenarios or that the Eagle Borg is going to take over and terminate all of us. I think the opportunities far outweigh the risks. But with that, there needs to be a decentralized open source and unfettered version of AI, that’s what InFlux Technologies is doing.

Founder Interview: Daniel Keller, CEO and Co-founder of InFlux Technologies

Apache Doris for Log and Time Series Data Analysis in NetEase: Why Not Elasticsearch and InfluxDB?

has become a popular way for sensors and services to store time-series data, and InfluxData makes that quick and easy thanks to InfluxDB Cloud. Some of the customers we've spoken to aren't storing everything in a managed cloud service though. Sometimes they have specific business, regulatory, or compliance reasons to store the data themselves in their own data center. Other times they're using multiple outputs in Telegraf to send data to InfluxDB Cloud as part of their disaster recovery plan. InfluxDB both Whatever the reason, having a single client connect to a private InfluxDB database securely potentially involves setting up network routes, opening up firewalls, adjusting NACLs and security groups. Not to mention navigating whatever internal processes might be involved to get all those changes approved and deployed. The value of InfluxDB isn't about having just one client writing data occasionally, it's about being able to support hundreds or more. So repeat that network administration overhead for each new device, or whenever a device's network configuration changes, and you've very quickly got a situation where maintaining those tight network controls becomes unsustainable. Most people would then weigh up between a couple of options: 1) Require a VPN be established between the remote client and the network InfluxDB database is in. (Potentially) Less on-going admin for the network admins where InfluxDB is running, but a higher setup burden for whoever is managing the clients. And do they really want their network connected to yours via a VPN? Or 2) Expose the InfluxDB database directly to the public internet, and trust the authentication system to be enough to protect it. Today I'm going to take you through a third choice. It'll only take a few minutes to implement, require no network changes, and will prevent you from having to put your private database onto the public internet. We'll also get a whole host of other benefits thrown in along the way which I'll cover once we've got it working. Note: The code examples below may change as we continue to improve the developer experience. Please check for the most up to date documentation. https://docs.ockam.io/ Initial setup If you'd like to jump straight into a working example of this, we have available on GitHub an that you can run locally with Docker Compose. It uses the official Docker images for InfluxDB and Telegraf, with changes to the startup scripts so each service uses Ockam to establish a connection. Full instructions on how to run it are included in the . InfluxDB + Telegraf + Ockam demo for Docker README To simulate an end-to-end example of a client sending data into InfluxDB we're going to start a Telegraf instance, have it emit CPU events to InfluxDB, and then change the way those two connect to show how we'd connect them across different hosts or networks. For the sake of this example though, we'll be running everything on a single machine. Ockam If you’ve previously setup Ockam you can skip this section and move straight to setting up InfluxDB below. brew install build-trust/ockam/ockam (if you’re not using brew for package management we have in our documentation) installation instructions for other systems Once installed you need to enroll your local identity with Ockam Orchestrator, run the command below and follow the instructions provided: ockam enroll InfluxDB If you've already got InfluxDB running on your local machine and have an authentication token you can use to write to it you can skip this section and move straight on to installing Telegraf below. The prerequisites for this section are to first install: InfluxDB Influx CLI Once installed we need to start InfluxDB so that we have somewhere to store the metrics data we're going to generate. On most systems that will be as simple as running: influxd You should then see some log output, with the final line confirming that influxd is now listening on port : 8086 2023-02-21T23:49:43.106268Z	info	Listening	{"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086} If influxd started successfully then you can open a new terminal session and leave this running in the background. If influxd did not start successfully check the for different operating systems. official documentation for some common issues Now we're going to use the influx CLI command to complete the initial database setup so that influxd can receive our data. Run the setup command and complete the required prompts, remember the organization and bucket names you use as we'll need them later: influx setup Next you'll need copy the token for the user you just created, which you can retrieve with the auth command: influx auth list Telegraf , and once it is setup we'll need a configuration file that defines our input source and our output destination. Telegraf thankfully includes a command to generate such a file, which we can specify to be preconfigured with the CPU utilization of our host machine as an input source and with InfluxDB as our output. Install Telegraf To generate the base configuration run: telegraf config \
  --section-filter agent:inputs:outputs \
  --input-filter cpu \
  --output-filter influxdb_v2 > telegraf.conf Open the generated telegraf.conf file and find the section which should look like this: [[outputs.influxdb_v2]] [[outputs.influxdb_v2]]
  ## The URLs of the InfluxDB cluster nodes.
  ##
  ## Multiple URLs can be specified for a single cluster, only ONE of the
  ## urls will be written to each interval.
  ##   ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"]
  urls = ["http://127.0.0.1:8086"]

  ## Token for authentication.
  token = ""

  ## Organization is the name of the organization you wish to write to.
  organization = ""

  ## Destination bucket to write into.
  bucket = "" Replace the empty values for token, organization, and bucket with the values from the previous section about and save you changes. You can now start Telegraf: setting up InfluxDB telegraf --config telegraf.conf Check it's all working To make it easy to re-use your values for future commands and testing, store the appropriate values (i.e., replace the placeholders below with your actual values) into a series of environment variables: export INFLUX_PORT=8086 \
  INFLUX_TOKEN=your-token-here \
  INFLUX_ORG=your-org \
  INFLUX_BUCKET=your-bucket Now we can check that Telegraf is regularly sending data to InfluxDB. The configuration we created earlier will emit CPU stats every 10 seconds, so we can send a query to InfluxDB and as it to return all data it has for the past 1 minute: curl \
    --header "Authorization: Token $INFLUX_TOKEN" \
    --header "Accept: application/csv" \
    --header 'Content-type: application/vnd.flux' \
    --data "from(bucket:\"$INFLUX_BUCKET\") |> range(start:-1m)" \
    http://localhost:$INFLUX_PORT/api/v2/query?org=$INFLUX_ORG Securely connect Telegraf + a private InfluxDB with Ockam The example above connects these two services, running on the same host, by using the default unencrypted HTTP transport. Most non-trivial configurations will have InfluxDB running on a separate host with one or more Telegraf nodes sending data in. In production it is unlikely that an unencrypted transport is acceptable, it's also not always desirable to potentially expose the InfluxDB port to public internet. In this section we'll show you how both of these problems can be solved with very minimal configuration changes to any existing services. Creating and enrolling your nodes The first step is to enroll yourself with Ockam, and create enrollment tokens for your InfluxDB and Telegraf nodes: ockam enroll
export OCKAM_INFLUXDB_TOKEN=$( \
  ockam project enroll --attribute component=influxdb)
export OCKAM_TELEGRAF_TOKEN=$( \
  ockam project enroll --attribute component=telegraf) Now we can create a node for our InfluxDB service: ockam identity create influxdb

ockam project authenticate $OCKAM_INFLUXDB_TOKEN --identity influxdb

ockam node create influxdb --identity influxdb

ockam policy create \
  --at influxdb \
  --resource tcp-outlet \
  --expression '(= subject.component "telegraf")'

ockam tcp-outlet create \
  --at influxdb \
  --to 127.0.0.1:8086

ockam relay create influxdb \
  --to influxdb There's a few things that have happened in those commands, so let's quickly unpack them: We've created a new node called , and enrolled it with Ockam using the token we'd generated earlier. If you look back at the command that generated the token you'll see we also tagged this token with an attribute of . influxdb component=influxdb We then added a policy to the node, which states that only nodes that have a attribute with a value of will be able to connect to a TCP outlet. influxdb component telegraf Next we create a TCP outlet. This is like a pipe from the `influxdb` node we've just created to the TCP port of `127.0.0.1:8086` (i.e., the port our InfluxDB database is listening on). This Ockam node will now pipe any data it receives from other nodes through to that destination. However the only nodes that will be able to establish that connection are those that pass the policy defined in the previous step. Finally we create a forwarder on our project, which now allows other nodes in our project to discover the and route traffic to it. influxdb It's now time to establish the other side of this connection by creating the corresponding client node for Telegraf: ockam identity create telegraf

ockam project authenticate $OCKAM_TELEGRAF_TOKEN --identity telegraf

ockam node create telegraf --identity telegraf

ockam policy create \
  --at telegraf \
  --resource tcp-inlet \
  --expression '(= subject.component "influxdb")'

ockam tcp-inlet create \
  --at telegraf \
  --from 127.0.0.1:8087 \
  --to /project/default/service/forward_to_influxdb/secure/api/service/outlet Now we can unpack these three commands and what they've done: As before, we've used the enrollment token we generated to create a new node and registered it with our project. This time it's the node. telegraf We've again applied a policy to improve our security posture. This policy allows a TCP inlet to be created, but only if the node at the other end has the attribute with a value of . component influxdb Finally we create the TCP inlet. This is a way of defining where the node should be listening for connections (in this case on TCP port ), and where it should forward that traffic to. This node will forward data through to the forwader we created earlier, which will in turn pass it to our influxdb node, which then sends it to the InfluxDB database. 8087 That's it! The listener on localhost port is now forwarding all traffic to InfluxDB, wherever that is running. If that database was on a different host, running in the cloud, or in a private data center the enrollment and forwarding would still ensure our communication with would be securely connected to wherever that database is running. 8087 127.0.0.1:8087 Update the existing configuration to use the secure connection This example created the TCP inlet on port primarily because the influxd service was running on the same host and already bound to port . In a production deployment where Telegraf and InfluxDB are on separate hosts the TCP inlet could listen on port and this default configuration would not need to change. 8087 8086 8086 While this is a simplified example running on a single host, the following instructions are the same irrespective of your deployment. Once the and nodes are enrolled and running, the only change you need to make is to update your telegraf.conf to point to the local listening port: influxdb telegraf [[outputs.influxdb_v2]]
  urls = ["http://127.0.0.1:8087"] Restart the Telegraf service, and we can then check that it's still storing data by using the same command we used earlier. Securely connected clients, and more... The example here has, in less than 10 minutes, solved our most pressing issue while adding in a number of valuable improvements that aren't immediately obvious because they've been abstracted away: Your InfluxDB hasn't had its port exposed to the public internet, and so there is no route for third-parties to access your server Private databases stay private: The secure channel that is established between your nodes is encrypted end-to-end. Each node generates its own cryptographic keys, and is issued its own unique credentials. They then use these to establish a mutually trusted secure channel between each other. By removing the dependency on a third-party service to store or distribute keys you're able to reduce your vulnerability surface area and eliminate single points of failure. Encrypted in transit: Authorization to even establish a route to the InfluxDB database is tied to the unique identity of the client requesting access, which is both more flexible in terms of support modern and often dynamic deployment approaches and also more clearly aligns with our intentions around access control. If they client is able to establish trust that they are who they say they are then they are able to route their packets to the database. Contrast that to historical approaches which a permanent access decisions based on assumptions about the remote network (e.g. is this request coming from an IP addess we have pre-authorized?). This is to the authentication and authorization controls on the InfluxDB database itself which will continue to work as they always have. Identity & Attribute Based Access Control: in addition The combination of all of the above means that the way to access the InfluxDB database is over a secure channel, which means all communication is encrypted in transit irrespective of any misconfiguration at either end (e.g., HTTP/TLS not being enabled). And because each node exchanges credentials with each other rather than sharing a common certificate or shared encryption key you can also be sure that: Secure-by-design: only No other parties in the supply-chain are able to modify the data in transit. The data you receive at the consumer is exactly what was sent by your clients. That only authorized clients can write to InfluxDB, ensuring that the data in your topic is highly trustworthy. If you have even more stringent requirements you can take control of your credential authority and enforce granular authorization policies. Ockam simplifies client access concerns by exposing all remote services as local services. We call this . When all remote components of an application become virtually adjacent to every other component, then the security and trust complexity of the entire network, the entire infrastructure, the entire internet is completely abstracted away. All third party intermediaries are removed from the app's vulnerability surface. Reduced vulnerability surface area: virtual adjacency Next steps If you haven't already followed the example in this guide, you can for free by following the instructions in our documentation. get started using Ockam If you’d like to talk specifically about this or other potential use cases for Ockam, the team would be more than happy to . chat with you Alternatively you can join us, and an ever growing community of developers who want to build trust by making applications that are secure-by-design, in the or on . Build Trust community Discord server Github Also published . here

How to Connect Distributed Clients to a Private InfluxDB Database

Cómo conectar clientes distribuidos a una base de datos privada de InfluxDB

Comment connecter des clients distribués à une base de données InfluxDB privée

वितरित ग्राहकों को एक निजी InfluxDB डेटाबेस से कैसे कनेक्ट करें

分散クライアントをプライベート InfluxDB データベースに接続する方法

Como conectar clientes distribuídos a um banco de dados InfluxDB privado

Cách kết nối máy khách phân tán với cơ sở dữ liệu InfluxDB riêng

如何将分布式客户端连接到私有 InfluxDB 数据库

At Flagsmith, we are working on building a . As we work through the struggles of surviving and thriving as a small software company, we connect with fellow founders to see how they built their open source projects into successful businesses. Most recently, we interviewed of on . commercial open source feature flagging product Paul Dix, co-founder and CTO InfluxDB “The Craft of Open Source” Podcast InfluxDB Origins The company was originally founded in 2012 by Paul, as a closed source SaaS product called “Errplane”. The focus was to help companies with real-time metrics and monitoring, but by 2013, it was clear that the product wasn’t taking off. Determined to find a market, Paul and the team realized that the time-series infrastructure they had built could be useful for other businesses. In September 2013, after not having the initial traction with Errplane they wanted, they decided to use the infrastructure to build a stand-alone time-series database engine. At the time, very few commercial companies and open source projects were focusing on time-series databases. The most notable open source project of the time was Graphite, which had become an orphaned project, but still retained a big following. The fact that this project still had engagement, but wasn't being driven forward in a focused manner, told Paul and the team that there was space in the open source community for a new time-series data base project. On the closed source commercial side of the market, there were a couple of time series commercial offerings at that time, but only in the financial data space - Onetick and KDB. However, these products were designed for a small number of time series that moved at high velocity, high frequency trading for example, which had a small data series that was updated 100,000’s times per second. Other applications such as sensor or server-monitoring data, demanded the opposite - with potentially hundreds of millions or even billions of unique time-series (especially for big companies such as FB or Netflix), that moved at a slower rate. Commercially, nobody was catering for this specific market back in 2013. As they looked at their own customer base, Paul discovered that many of their existing Errplane customers were just using the application as a time-series solution, building on top of the API using the generic dash boarding solution to handle their time series. The product was beginning to take shape along with the open source opportunity... The Seeds of Open Source InfluxDB Most companies that were trying to “roll their own stack” were using Graphite, which is a limited “round-robin” database, only designed for regular time series. In other words, it  takes samples at fixed intervals - e.g. sampling once per minute, and not in real-time. This meant it could only be used for metric measurement. As Graphite was not designed for large scale applications, Paul saw an opening for event data time series - logs, exceptions, individual requests through an API, etc. which all use time series data that Graphite couldn’t handle. Anything above a quantity of 100,000 data series would fall down with Graphite, making scaling difficult. At the time, most database engines were focused on NoSQL, such as MongoDB, which became the number one NoSQL engine. Paul watched MongoDB closely and learned from what they did, in particular how they nailed the developer experience. They made it super-easy for developers to build their application quickly and become more productive. So, Paul realized it was important to make InfluxDB super-easy to use, helping developers to work faster, and build a time series app as quickly as possible. Paul decided to go the commercial open source route and follow a simple 4 step process to create InfluxDB: Create an open source project Make it hugely popular Monetize it somehow Generate profit In other words, Paul started without a clear monetization plan, but was confident that there would be some way to make money further down the road. The important thing was to make it open source as that was the only way developers would buy into it. InfluxDB started as a greenfield project, brand new code, but built from the infrastructure of the SaaS product. To make it user friendly, Paul implemented a query language that looks and feels like SQL, but with their own parser and executor, etc. InfluxDB was ready after 5 weeks of coding and was released using MIT-licensed open source libraries. The goal was to create an open source distributed DB with no external dependencies. In other words, you install and you’re good to go. Initial Funding For The Project Back in 2016, the series A round of funding raised 8.1 million. It quickly got to a point where the project needed series B funding. Normally you need to show proof of some significant revenue to get series B, but InfluxDB had none at the time. Paul realized that one way to monetize, was to offer high availability and scale-out clustering. This had the potential to make money in a closed source way. , Paul goes into detail about how they monitored popularity and community growth using a variety of metrics, and a "phone-home" feature which gave them some data on how it was being used. In the podcast Of the first 10,000 servers by Jan 2016, 99% were individual servers, not clusters. This wasn’t surprising. All the traction InfluxDB had gained so far was focused on what you could do on a single server only. Paul recognized that they could make a closed source version of the product that would offer a service for high availability and scale-out clustering. Going Commercial In March 2016, Paul wrote a blog post announcing that all future versions of OS influxdb would be single server only, and there would be a commercial version for clustering. This made the front page of HackerNews and generated some criticism - people accused InfluxDB of doing a “bait and switch”. On the plus side, there was immediate interest, with people contacting and asking how they could buy the commercial version. , Paul discusses how their philosophy was to make their open source completely open, licensed through MIT for example, and make the commercial products completely closed source and the reasons for this. In the podcast He also states his dislike of source-available code, which doesn’t allow for a clean implementation. Source-available is only good for a freemium product, similar to old shareware games where you’d get a free version that you could upgrade to a paid version. But that is not open source. Paul believes that true open source means that anybody can take the code and build a business from it. Therefore, InfluxDB maintained their open source single server engine, but the clustered version is a paid product. Paul recalls how this was a gamble at first as they weren’t sure if there would be enough interest in buying the product, and they risked losing the support of our OS community as a result. Commercial Success For InfluxDB Fast forward to now, and the business is built around the paid clustered version. They now have two offerings - an on premises, site-installed version and a cloud-based service hosted on AWS. The cloud version allows you to pick a size, and they provision the new cluster for you, install the software, monitoring systems, and run them. By Jan 2018, they were generating consistent revenue, so they raised series C funding which equated to around $30 million. 2018 was even better, so in Jan 2019 they raised series D funding of around $60 million. This was all based on commercial traction from the single paid product. The OS community has grown massively too - from 10,000 servers in 2016 to more than 400,000 single servers today. Introducing InfluxDB Iox Paul has recently announced a new project that he’s building called InfluxDB Iox, which is a new core time series engine, written entirely in Rust. Iox is an in-memory columnar store with object store optimised for time series, but it’s also a system for defining replication rules, and data partitioning rules within a set of servers. The idea is to create an open source engine that continues doing what Influx is good at, but also adds best-in-class performance for larger scale analytic queries. The commercial aspect of this new project is to run it as a cloud-based solution. The cloud based version requires extra software to coordinate and operate a fleet of servers. This software is closed source and will be on a paid licence. Instead of running open source code, then upgrading to the paid version if you want high availability or scale-out capability, which is a big ask, Iox takes a different approach where the commercial product is complementary, rather than an entire replacement of the open source version. In other words, if you switch to the cloud version, you’re making the running and management of the servers easier and you’re not turning anything off in the process. Paul sees Iox a big win both technically and architecturally. The separate cloud-based software idea makes the whole thing much more flexible for the operator, allowing them to apply a number of different cluster topologies and operational environments. In the podcast Paul goes into detail on how Iox works and how everyone in the ecosystem can benefit from it. His ultimate goal is for Iox to crack the top ten in database engine rankings. The 2.0 cloud product is designed to give much more control over the DB and operations. When moving from InfluxDB 1.0 to IOX 2.0 there will be no customer downtime or migration issues. For open source users, Paul plans to make IOX available as a backend to be used with InfluxDB next year. Paul believes that Iox won’t split the community, as 1.0 and 2.0 are complementary. Most people use InfluxDB around the edges, not as a core database. Iox brings in API compatibility, so people who use it around the edges at the moment, will be able to use it in the same way, and people who want to create a new core database can use it too. Check Out the Podcast If you want to find out more about open source InfluxDB and the new Iox project, then which goes in-depth into the projects, and on the topic of open source in general. listen to the podcast

InfluxDB: From Open Source Time Series Database to Millions in Revenue

The year is 2020, and everyone is excited about the unpredictability of its rollercoaster ride. We are all strapped in and are ready to go, but there are still some vacant seats. The rollercoaster refuses to set sail unless all seats are with occupants. We do not understand this seer nature of 2020 and why it is bringing these new terms and conditions into play. We, however, have some candidates in mind to occupy the vacant seats. Their inevitable existence has been in the shadow of our minds for some time. But now its time to let these cousins of ours into the fold. Enter the robots, and the 2020 rollercoaster ride commences. We as humans, however, insist that we captain the ship and must decide on which route the year should sail since we have more experience. The year 2020 ended on a positive note with 2020 expected to introduce a wave of robotic phases. Everyone was excited about the T robotic debut that intended to make a statement about the new robotic era. okyo Olympics 2020 However, the surprise of the Covid-19 epidemic pushed the event to July 2021. The human prone industrial segments were also in a bit of disagreement on how fast the robots were taking over the industry. The manufacturing and retail sectors led the protest until Covid-19 showed its daring face. However, the onset of this fatal virus gives us more reasons as to why the robots are only our nemesis in the Terminator sequel movies and not in real life. It is no longer about fighting for a job opportunity but the survival and prosperity of the human race. We all at some point looked at robots as the workaholic that never tires nor complained, but now they are also our go-to safety net against pandemics like the Covid-19. More than ever, this pandemic has increased the trajectory need for robots in the fast-paced facilitation of goods and services. Thus the demand for robotic technologies is now higher than the thirst for oil and gold. Let us step into some trends and opportunities in play: 1. Healthcare The onset of the Covid-19 plague brought a dark cloud to our world. The robots and robotic gears have been vital in managing its spread and containment. Since the Coronavirus preys on human contact, the healthcare medical personnel had to find a way of treating the affected patients without too much exposure to the same patients and their environments. Thus issues like disinfecting the healthcare facilities and medical equipment can be thorough and efficient . Mass disinfection of affected areas with an isolated population can be effective through drones that can monitor, survey, and spray aerosol. Hence through robots, it is possible to run healthcare routines remotely. robots The role of the need not stop at the Covid-19 level as it is a gateway to their permanent stay in the medical profession. They can be competent in assistive surgeries, record-keeping, and patient dosage monitoring. We already have the into the fold, and thus, it is safe to state that it is an excellent opportunity for the nursing homes for maximum healthcare. healthcare robots robotic nurses 2. Food and Nutrition The most important lesson from the outbreak of the Covid-19 pandemic is that we need to be more vigilant in our social ways, especially when handling food. Hence it is prudent to get the assistance of a robotic arm nowadays as a safety precaution. Since we cannot rely on our hands to make coffee, especially in a public environment, the likes of the robots under are already a step ahead. They are in their own secret coded language telling us that Covid-19 might change our lifestyle, but it will never in any way affect the way we take our coffee. You only get to interact with such robots on your coffee venture and not risk human social contact masking the Covid-19. Rozum Cafe Such robotic baristas are already causing ripples of excitement in the technological space. It is because they are the founding fathers of what is to come. We are already hearing of robots making hot dogs. The mastery of in making snacks and appetizers will very soon lead them to a 5-course meal achievement. We are likely to drool every time a robot will step into the kitchen to prepare a meal. simulations foodservice robots 3. Automobiles Such a fast-paced journey into the robotic world requires the comfort of an automobile environment. The robots are peacefully yet aggressively invading the automobile industry with good intentions. We would no longer need a tire behind the starring wheel of a vehicle and risk getting into accidents. The are gaining more recognition. They are what the world needs to redefine its routes. The in the self-driving vehicles will help in analyzing the possibility of taking an alternate route through a decision-making algorithm in regards to traffic congestion and accidents along the way. They also have a hand in the delivery of medical supplies during this Covid-19 pandemic. Companies like Alibaba have for delivering ordered products from their online platforms. Thus we can comfortably state that our 1000 mile journey is purely robotic. self-driving cars technological improvisation robot prototypes 4. Retail Since our presence in the public limelight is becoming scarce each day due to us being the favorite prey of the Coronavirus, it is only logical that the robots occupy some of this space for business to continue. The retail stores require a lot of record-keeping, invoicing, and fetching reports. Since the are the masters of this craft, they can fetch an item for a customer and update the records based on the numbers sold and those remaining. They, moreover, help the users and customers in discovering the location of specific products. These also portray social traits like smiles and greeting customers on their way into the store. Their presence is no longer a prediction but a situation already in play. retail robots improvised robots 5. Manufacturing The manufacturing world continues to reap from the strength of long powered robotic arms. They are priceless in lifting tons of goods at warehouses and in effortlessly tackling tasks that might put human lives at risk. With industrialization seeking a rebirth this year, the are at the frontline for a fast pacing task assignment. Fast production is the theme of their work ethics. manufacturing robots The year 2020 is trending with a lot of opportunities for some with an intension of fully transforming the industry. robotic candidates So it would be wise to reserve a rollercoaster seat for a robot friend for they have earned their place in the human fold. The onset of the Covid-19 pandemic came at us with everything it got and forgot about the robots that always have our backs from day one. It is thus a wake-up call, and we should be wary. Covid-19 was not the last attack on humanity, but it is the last attack to surprise us. With robotic technology as our prime weapon, any social or economic warpath should be afraid of us. The robots are creating for us a blissful technologically-driven future with all expenses paid; we just need to say yes to the offer.

Five Industries That Could See An Influx of Robots

Introduction The security and monitoring of sensitive data is critically important to us, since customers are placing their trust in our product. That’s why we try to monitor everything, resulting in an enormous amount of data points in our time-series DB. So, what do you do when your data exceeds your cloud storage plan and you start to get outages? Start implementing a retention policy and downsampling scenario for old data aggregation. Brief overview of our metric capture infrastructure: InfluxDB for storing or metrics in the face of ` ` influxcloud 20+ metrics Time precision to milliseconds 20+ mil points per measurement 1 year of historical data Real-time customer-facing service based on this data Traditional approach We use InfluxDB as our storage solution. It’s the highest-ranked time-series DB on the market, and rightfully so - it offers a very good set of tools to work with and visualize your data. So you want to go the traditional way, and here InfluxDB has you . For this to work, you need to be aware of two things: retention policy and continuous query. covered is a part of InfluxDB’s structure, like a scheme in RDB that also stores how long InfluxDB should keep data. A database can consist of several retention policies that contain measurements. By default, at database creation, InfluxDB creates an `autogen` retention policy with an infinite retention period. Retention policy : a query, written in InfluxQL, that runs automatically and periodically within a database. Continuous query Our goal is to create one more retention policy within the same database where data are pushed from the default retention policy. Let’s consider these 5 records for downsampling to a one-hour period. Things look easy. All we should do is: 1. Create a new retention policy with infinite retention duration INF CREATE RETENTION POLICY "iceberg" ON "access-metrics" DURATION REPLICATION 1 2. Create a continuous query for every measurement we want to be aggregated CONTINUOUS ( ) , . ( h), * CREATE QUERY "upstreams_cq" ON "access-metrics" BEGIN SELECT sum "values" AS "values" INTO "iceberg" "upstreams" FROM "upstreams" GROUP BY time 1 END asterix (*) on . We have tags-heavy data, and we need to preserve them during the aggregation process Notice: GROUP BY 3. Aggregate historic data using the same query ( ) , . . . . ( h), * SELECT sum "values" AS "values" INTO "access-metrics" "iceberg" "upstreams" FROM "access-metrics" "autogen" "upstreams" GROUP BY time 1 As a result, we will get something like this: 4. Push new retention period on default retention policy d ALTER RETENTION POLICY "autogen" ON "access-metrics" DURATION 365 This is a neat out-of-the-box solution, and it works! … to an extent. Let's take a look at the InfluxDB : notation In InfluxDB, a timestamp identifies a single point in any given data series. This is like an SQL database table where the primary key is pre-set by the system and is always time. Since all three of these records have the same timestamp, they 'silently' override each other during insertion without any private key violation constraints. This solution is perfect for a simple case without tags in aggregated data. Using it with tags-heavy data would result in several entries with one timestamp that would overwrite over each other, causing each time period to have only one entry. Our approach So what can we do to improve InfluxDB downsampling so that it would suit us? Code it! We already have a service that encapsulates all knowledge on our metrics - why not extend it with downsampling capabilities? Let’s revise our plan: 1. Create new retention policy with infinite retention duration INF CREATE RETENTION POLICY "iceberg" ON "access-metrics" DURATION REPLICATION 1 2. Schedule aggregation query: ( ) , . ( h), * SELECT sum "values" AS "values" INTO "iceberg" "upstreams" FROM "upstreams" GROUP BY time 1 3. Modify timestamp of aggregated entries, so that it would be distinct within the aggregation period 4. Aggregate historical data using the same query with timestamp modification 5. Push new retention period on default retention policy ALTER RETENTION POLICY ON DURATION d "autogen" "access-metrics" 365 By diversifying the timestamp by adding milliseconds, we are preserving all the results of the aggregation and making an import case work, that would not just work out-of-the-box. It may not be elegant, but it works! Autogen metrics graph Downsampled metrics graph Conclusion When you are dealing with tons of data, you need to think of downsampling InfluxDB has good built-in mechanisms for data retention InfluxDB continuous query is a good way to organize data aggregation If you want to preserve tags upon aggregation, you will need to write your own logic on top of InfluxQL Don’t be afraid to write around the limitations of well-established products

InfluxDB Continuous Downsampling  - Optimize Your TSDB Today

This post will walk you through each step of creating interactive, real-time & dynamic dashboard to monitor your instances using , & . MySQL Telegraf InfluxDB Grafana Start by enabling the input plugin in : MySQL /etc/telegraf/telegraf.conf Once Telegraf is up and running it’ll start collecting data and writing them to the InfluxDB database: Finally, point your browser to your , then login as the user. Choose ‘ ‘ from the menu. Then, click ‘ ‘ in the top bar. Grafana URL admin Data Sources Add new Fill in the configuration details for the data source: InfluxDB You can now import the file by opening the dashboard dropdown menu and click ‘ ‘ : dashboard.json Import Note: Check my for more interactive & beautiful dashboards. Github Grafana

MySQL Monitoring with Telegraf, InfluxDB & Grafana

The Cyclicality of the Crypto Markets Shows Its Hand Once Again

Donald Trump, $80k Bitcoin and the Strategic Bitcoin Reserve

Stories, News & Mentions about INFLUX

Influx’s Stories on HackerNoon