Hi there, and thank you for tuning in. My name is Sarah Furie, and I'm the new Head of Client Services at Paper of South Africa. I've been with Paper of Fover team years and was Head of Sales for the past five. I now oversee the Best in Industry Client Services team of 16 dedicated and amazing people with competencies across three areas of excellence, onboarding, support, and customer success. Together, we help rental agents use their time more efficiently to achieve rapid and sustainable growth while enhancing the way they manage their trust environments. Today, I'll be presenting what I like to call Rental Management Rocket Fuel. Tips and tools for rental managers, administrators, and principals that will help you launch your business to new heights. I'd like to start by discussing compliance, which should be one of the top priorities for every property management company. The new Property Practitioners Act, or PPA for short, came into effect in February and governs the activities of all property practitioners in South Africa. Amongst these regulations are stringent rules about the signing of mandates, disclosure with regard to properties, introduction of and dealings with lessees, and the management of funds pertaining to property rentals and sales. Legitimate landlords and property owners will only want to work with agents who abide by the PPA and ensure that property transactions are legally compliant and ethically sound. Section 54 of the PPA states that property practitioners must keep separate trust accounts for their client's trust monies. These accounts, plus the practitioner's business accounts, must be audited every year. As per the previous requirements, these annual audits should be undertaken by accredited auditors. However, the PPA introduces the possibility of exemption in sections 4 and 23. In terms of section 4, any person may, subject to specific provisions of the section, be exempted from compliance with any specific provision of the PPA. Section 23 offers the possibility of exemption from keeping a trust account under certain circumstances and states that exempted property practitioners' accounting records may undergo a different, lighter reviewing process. Regulation 2 provides further details, with Regulation 2.1 outlining the circumstances in which this can happen. Property practitioners will need to apply for exemption because the process does not happen automatically. Once exempted, you can have your accounts independently reviewed by a registered accountant, which will be far easier and cheaper. Property practitioners must also use accredited payment processing agents, such as paper-up, to be exempted from operating their own trust accounts. In addition to a section 54.1 trust account, there needs to be an interest-bearing section 54.2 account, within which all damage deposits are held for the duration of the tenancy. These funds need to be safely administered, accounted for and paid out to the tenant at the end of the lease period, unless of course there were deductions for damage to the property, lost keys, etc. For our client's peace of mind, and to help agencies across South Africa maintain an exemplary compliance statement, we recently published a furbished, fully compliant, template lease documentation in line with the new relevant legislation and regulations, including the Protection of Personal Information Act, number 4 of 2013, puppy, and the Property Practitioners Act, number 22 of 2019, PPA. These are available to our clients for use or guidance, should you prefer to update your own documents, free of charge. But before any of these contractual procedures are set into motion, you need to prospect for landlords and source good tenants. Without an effective approach to sourcing both, you won't be able to grow your business. The best method for signing more landlords is to first understand what they want, to have the investments taken care of diligently and to receive their rent quickly and in full. To ensure this, you need to offer a streamlined and secure payment service, with all the features that landlords just can't resist. This goes a long way in reputation building and gaining referrals. As any rental agent knows, recommendations are essential for growing your business. Not only do they provide a valuable source of leads, but they can also help you build relationship with potential clients. But to earn referrals, your service should be impeccable. That is the most powerful recommendation of all. At PayProp, we also provide our clients with marketing materials as an aid when pitching to prospective landlords. Our brochure outlines landlord-specific benefits, such as the PayProp owner app, free of charge on iOS and Android, which give landlords quick and easy access to their portfolio's payment data anytime, anywhere. This makes tax season a breeze, as landlords can easily retrieve their rental income from the year on their mobile device, cutting down on landlord inquiries. The next challenge remains one of the biggest for intelligence, finding quality tenants with acceptable credit scores, sufficient funds for one-time damage deposit and enough income to pay the rent every month. After all, growing your commission means growing the amount of rent you collect and without good tenants that pay on time, your landlords and your business won't thrive. An experienced rental agent will not only initially identify a good tenant for the landlord, but they will also manage their relationship and advice on any reasonable rent increases in the current climate. A good rental agent will know what's acceptable in their local area and can provide the reality check needed to help manage expectations. Prospective tenants' payment history can be requested using PayProp's market-leading tenant assessment report. This report combines a traditional credit score from a credit agency with past rental payment data from paper-powered agencies. This gives a better indication of a tenant's ability to pay the rent as it includes real payment data from previous tenancies. Paper-powered agencies from across South Africa can choose to contribute to this database. We may have information on a tenant's payment history if they have previously rented a property via one of our current clients in any province in South Africa. This information enables other agencies on our books to choose renters for their landlords more wisely. Once the tenant is placed, the monthly reoccurring admin begins. The best rental agents prioritize communication. Rental management is a people business after all. When dealing with landlords, tenants and associated providers, keeping communication professional, timely and accurate is essential. Traditional payments, rental payment workflows would require agents to type an email and invoice to every tenant every month for the duration of the tenancy. Once the tenant makes the payments, it then needs to be identified, allocated to the right property in the relevant trust account. At this point, a receipt also needs to be written and sent to the tenant and a statement to the landlord showing receipt of the rent and any deductibles. There is a risk at every step that someone will make a mistake as each document needs to be created and updated manually each time. With PropTech however, all of this client communication can be automated and trusted as each document is a complete statement of live transactions taken directly from bank records. These statements cannot be edited or deleted, giving all parties confidence that the money shown in the statements has been distributed as outlined. Trust is easy to break but it's easier to gain when you provide your owner's data that is bank-informed accurate. I asked Michelle Deccan's industry innovator LiveWider Media Presence and Paper of South Africa's new deputy CEO for tips as we head into the festive season. She advised invoice tenants earlier than usual in the month of December. So even though they didn't know need to pay right away, they'll have been reminded not to spend all of their hard-earned rands on holiday shopping that they may receive earlier in their month with an earliest payment salary run and then have nothing left to pay the rent when the time comes. Reconciling rent payments is one of the most cumbersome and stressful processes a rental agent must go through. As the chances of allocating the wrong payment to the wrong tenants and property is high in trust environments that rely on manual bookkeeping. For example, it's easy to get confused if you have multiple properties that charge the same rent. With a smart payment processor rent paid by bank transfer, debit order or instant EFT arrives in your trust account pre-reconciled, making it impossible to allocate rent payment from tenant A to property B. And even if a tenant uses the wrong reference number, which when paying the rent, paper will suggest a property match based on intelligent criteria like the tenant's name, address, invoice amounts and more. Receiving money into paper up and paying it out again is a straight-through process, only requiring your approval at the reconciliation and the distribution stages, though this too can be automated to happen automatically. Once a rental payment is automatically reconciled, paper allocates the money based on the payment rules you set up when you first added the property to our platform. Firstly, your commission is paid. Next, any payments to contractors and monies allocated to the property accounts are apportioned. The remainder is then sent to the landlord. This process can be automated and only requires your approval. This process also gives you a comprehensive record of the money from the moment it inserts your trust account to when it is paid out. As paper up is integrated into the banking system in all countries we operate in, rent can be paid out faster to landlords, contractors and your commission accounts. Attract the best workmen and contractors, safe in the knowledge that you can pay them faster than your competitors. Let's review, shall we? A tenant wants to rent the 12,000-rant two-bedroom duplex he found on private property. He completes the tenant application form, the paper of tenant application form, which gives consent to run a successful credit check. He then signs the lease agreement. A good payment platform will enable you to create a recurring invoice for the duration of the tenancy, determine and facilitate the tenant's payment method. For example, if you choose debit order, paper will automatically withdraw the money from their bank account every month, establish a flexible and powerful settlement rules and, four, stay compliant with the PPA's regulation for trust accounts. Your job is now essentially done with regards to this tenancy. Paper will automatically send out the invoice, collect and allocate the monies, set up their outgoing payments, correctly apportioned and staged for you to just simply approve. Once you approve the outgoing payments, the platform will pay all beneficiaries, that's landlords, commission accounts and third party providers in the correct order, send them payment notices, update and send tenant statements and update and send owner statements, store the proof of payment on the platform for future reference and then auto-reconcile the trust account. With those key administrative tasks automated and taken care of, you and your team can now dedicate more time to prospecting new landlords and securing good tenants to grow your business. But what else does an agency need to boost its rental management? Well, the right tech will help your company grow without putting a strain on your staff. The basic tech tools needed to run a rental portfolio include, means to communicate with staff, owners and tenants, WhatsApp for example and an email marketing service like MailChimp, cloud storage, social media accounts, a subscription to listing portals like private property, business accounting software, inspection and maintenance tools and a rental payment processor like PayProp that includes nearly all of the above plus more. One new development we've added to our platform this year is an integrated maintenance feature, which gives our users a simple and convenient way to manage maintenance and repair tickets directly from the platform. You could use this feature to let tenants log maintenance ticket themselves, create your own maintenance tickets, maintenance tickets to inform the tenants of plan work, to communicate directly with tenants about maintenance issues through the tenant portal, add private notes to tickets to keep colleagues up to date, store PDF invoices and images on any ticket and automate email notifications to tenants every time you update the ticket. Agents who make use of a good payment processor have several additional tools at their disposal that help them streamline their day-to-day operations on the platform and make their lives easier. PayProp also offers landlord and tenant visibility and self-service through the owner app and tenant portal. Tenant screening with a tenant assessment report, instant online payments with Oso integration and other industry leading functionality included free or at a minimal cost. Some of you may remember Samantha Ferrera, Matia, who is now head of client services for PayProp North America, asked her for some tips on how to optimize your property portfolio. She said, whether you use PayProp or another system, your property rental portfolio should receive the same ongoing care and maintenance that you would give to your home to ensure everything in its order and you're getting optimal use out of it as well as peace of mind. A disorganized portfolio, clogged with junk data or hiding loose ends or enabling wrong doing through lax processes can disrupt the flow operations, reduce productivity, expose the business to risk and ultimately cause sleepless nights. So here are six checks you can perform regularly to keep your rental portfolio in peak condition. One, check for deposit consistency. Quite simply, you should have the same number of damage deposits as they are active tenants on your portfolio of rental properties and their individual value should be roughly equal to the monthly rental value. Any cases of active tenants who don't have deposits should be looked into unless there's a valid reason for it. This will clear up any confusion around absent or oddly valued deposits and can be a starting point for any deeper investigations that may reveal other irregularities. But it's inactive tenants who still have damaged deposits against their names that you really want to keep a close eye on. Check for this regularly to ensure that deposits are paid out as soon as possible after tenant has moved out. Once that's resolved and for added peace of mind, properties on pay prop can be disabled upon vacancy at which points reoccurring invoices will stop automatically. By clearing out expired contracts and ensuring that money is always returned to his rightful owner, you can keep your books tidy and your business honourable. Number two, verify credit notes. Credit notes, credit memos, journals, entries, no matter what you call them, they should be used to correct mistakes. Or when funds from another source, like a damaged deposit, were used to reduce an outstanding amount. And to be clear, this should be highly exceptional and not the rule. Otherwise, excessive or unexplained credit notes pose a risk to the principal. Take a look at how many credit notes were created in relation to the number of invoices generated for the same period. Make sure that each one includes a clear description of why it was created to avoid any misunderstandings. Any discrepancies are worth investigating. Pay prop's customizable permission settings allow you to restrict only authorized users to create credit notes. Three, monitor credit balances. It's important to not only check the tenant's statements to see if specific accounts are in credit, but also whether they are in arrears. A portfolio becomes messy when arrears are not handled promptly. And the messy it gets, the harder it is for the principal to analyze or recoup outstanding amounts which increases risk. Pay prop's advanced arrears take automatically flags when a payment is missed and allows you to chase any outstanding amounts over email and SMS. Our system gets results. 64% of tenants respond within 48 hours. Additionally, whether the tenant over or underpaid due to inaccurate additional or missing charges on their invoice, you can prevent by having to explain a miscalculation later by regularly checking that the tenant's statements are correct. Number four, manage notifications. Enable, if you can, notifications to beneficiaries, for example, owners and payers, for example, tenants, whenever a transaction is made on your rental portfolio. It could be the single most important move you can make to reduce arrears, emissions and miscommunication. Pay prop's automated and bank accurate client communication keeps everyone up to date on the status of their monies. Number five, action outstanding invoices. A general daily sweep of your outstanding invoices can save you time and money in the long run. Try to ensure that even small pending deposits are not left unallocated as they can add up and become costly. Failed beneficiary payments can alert you to issues that are easy to overlook but important to address, such as close accounts or incorrect banking details. Pay prop's landing page is your dashboard, giving you a live comprehensive portfolio summary that includes the amount of outstanding invoices every time you log in. I also spoke with Denise LaRue, one of our platform experts and support specialists who also host our monthly online training events. Denise started out as a rental administrator herself over 20 years ago, so I asked her for a practical hack for newcomers to the rental industry. She suggested highlighting action dates on a calendar as a visual aid while learning how to get into the monthly rhythm of managed rentals. She says knowing what happens when it takes the guesswork out of remembering important deadlines. For instance, take a yellow marker and highlight your variable payment rule action date, for example the 18th or the 20th of each month on your calendar for whole year. Then take a blue marker and highlight your automated fixed payment rule date as the 25th of each month on your calendar. She would also suggest taking a third color, maybe green or something soft on the eye, and identify how many days in advance the rental invoices generate. This is called the lead date on pay prop. Often it's three, five, seven or even 10 days before the end of each month. When pay prop pre-generates, the reoccurring invoices and sends it out to your tenants by email or SMS. You can use the same life hack even if you use a digital calendar. Take advantage of these tools and processes, either as a pay prop client or in your existing setup to maintain the integrity and health of your rental portfolio. If you do, you will raise your value proposition to your clients, helping you to grow your business. And that concludes today's webinar on rental management rocket fuel. Thank you for joining me today. I'm Sarah Furry, head of client services at Pay Prop South Africa, and I hope these tips helped with the for the help, the growth of your business blast off in the near future. Thank you.


So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, whoever's not talking can do it, I mean, if there's not, once I hand off to Rika, I'll just sit here. So, thanks again for coming. There's a few organizational messages while the guys are solving the technical difficulties again. So, please mute your mobile phones, please keep the room as clean as possible. When you really need to leave, please keep the doors as quietly as possible and close it again, please. Don't forget to vote for Lightning Talks Day, the take part tomorrow. And there's a party tomorrow, as you may know. I think the tickets are over for today, but there should be more tickets tomorrow at the Red Hat recruitment booth at the entrance. But sit for me and now I hope the guys from OpenShift will take over. Okay, good afternoon. Nobody breathe, okay? Because this thing is... Did it just go off again? Yeah, it's on. Do you want me to get my laptop? So, we're going to go with this. We have some color abnormalities, but that's okay. So, welcome to our talk about CICD Continuous Integration and Delivery with Jenkins and OpenShift. This is really a tools kind of discussion, but we want to recognize from the beginning that CICD practices are not just about the tools, right? This is about a culture where we're thinking differently about how we deliver software, how we test software, and it does have a big impact on the tools, but it's just as much a part of how we collaborate, how we think about who does testing and who does development and who does the deployment to production and that type of thing. So, we want to try to keep that in our mind, but we're really going to just be talking about the tools, I think, primarily today. And what we're going to go through briefly is kind of the goals of the project and the demo that we're going to show, the kind of the Jenkins setup and those kind of details, the workflow that we've set up in kind of a generalized way that we'll be demonstrating and then provide some opportunity to see things work where we've got a short demo and then we'll have some questions. So, just briefly, why containers, why are we using containers in our testing and in our deployment and development work? So, speed is a huge thing and just the whole agile nature of how quickly that you can work with containers, deploying them, replacing them very easily and quickly, you're forced to treat them as cattle, you know, there's lots of these things. And you don't care if one dies or one's broken, we're going to rebuild, we're going to redeploy that kind of thing. So, and we're trying to bring that whole microservice buzzword, if you will, into the way we test, not just in the way that we build our application and deploy it, but also the whole infrastructure that provides that deployment pipeline. So, we want to kind of dog food containers across the board. And the other is how many of you have a system that you maintain or whatever that you've spun up at some point and that if it goes down you really don't know what you would do because, you know, you just spun it up one weekend and you didn't provide maybe storage that was backed up and maybe, yeah, it's kind of on this other part of the network that isn't real robust.  And we find that working with containers, a lot of times it requires you to think about persistence and how, if this thing dies, what's going to happen? What if my database isn't backed up and all that kind of stuff? So, we start to think about, a little bit more disciplined about these things. It's kind of a pain sometimes, but it's actually probably a good thing in most cases to think about persistence, state, decoupling your application from your data. I don't remember what the last thing was. What was the last thing? Reproducibility. Okay. And I think that gets to the other, you know, about persistence and being able to spin this thing up in a reproducible environment. Okay, next. So, why OpenShift? I think, for me, whenever I started working with containers, it was kind of as a toy, right? You have this thing and you play with it and then you have another thing and you play with it. But when you're serious about things, you've got problems and you need some type of platform to orchestrate these things, to provide networking, to expose ports and provide routing DNS to certain services, to link services together, all that kind of stuff. OpenShift starts to really solve some of those problems, so you don't have to worry about those things so much. Just having templates to manage your microservices is really a useful pattern. And also, just having this kind of integrated system, you know, when you're dealing with containers, you're always going to need to build, you need a place to put that build, like a registry. You need a way to, you know, manage kind of that whole pipeline, so we've got a Jenkins service and maybe some slaves over here, and you've got to build this too. So, now you've got lots of containers you've got to build, lots of containers you need to store, lots of containers you need to maintain and orchestrate when they come up and down and when they're updated. I mean, this gets complicated, right? So, that's one of the benefits of having a platform. And I think one of the really interesting things that OpenShift provides is not at all utilized to its fullest. It's really just kind of being introduced, I think, to my thinking, is this source-to-image. And that's a way of layering a small amount of your application onto a Docker image, and it provides a very quick way of customizing an application. It's a very lean kind of quick pattern to provide a common set of images and then just having the unique data layer on top of each one. And we'll see how that works in the Jenkins slave example that Mika will show. So, the goals were really to kind of generalize this container-based pipeline. You know, everyone has unique needs, but we do want to provide some of these basic, you know, hooks and automation type of patterns that you will need in any project. And certainly there's going to be lots of customization that's going to need and it's going to be required, but hopefully you don't have to spend so much time with the basics that everyone has, all the basic problems that we all share in common. And really the goal is to prevent the promotion of broken builds. We can build all day a thousand times, and if it's broken, that's okay, because we're not going to promote it to a place where it's going to be critical. When we promote it to a stage environment, then we're going to have some confidence in that time on that 1001 build. So, I think I'm going to hand it over to Mika to talk about the Jenkins work. Yeah. So, hi, my name is Mika and I'm working in Redhead as a software engineer. So, I'm actually responsible for the developer experience part of OpenShift. So, I'm working on the Docker images that OpenShift provides. And as part of that, we think that the CI, CD flows and Jenkins fits to this. So, I also work on the Jenkins and continues delivery, continues integration with OpenShift v3. So, this will be part of the demo. So, you will see how this works in practice. So, I will just briefly talk through what you will see there. So, what we, what you can do in OpenShift nowadays, you can run Jenkins as inside the container as OpenShift. So, OpenShift can also run the slaves that the Jenkins use for building your application, right? So, in the normal world, the slaves are the virtual machines that you build your application, right?  And what we think is more cloudish way to do this is that you spawn a slave as a pot in Kubernetes when you really need it, right? Like, I don't need to have the virtual machine hanging out doing nothing. So, every time I need a slave, every time I need to test or build my application, I will just create the pot and run the test or whatever I need there and get the results back. So, the Jenkins image that we have in OpenShift, initially, we start adding a lot of features to it.  And then, at some point, we say, like, no, this is too much, right? Like, we are putting a lot of features to a Jenkins image and this is not how the world works. So, we can't satisfy everybody and people usually use different configurations for Jenkins, they use different jobs, they use, you know, artifacts that they want to deploy in Jenkins. So, we thought, like, it will be cool if Jenkins can be an S2I builder. So, we treat your Jenkins configuration, your jobs, your plugin as a source.  So, the S2I allows currently customization of the Jenkins image. So, you just give us your git repository and we'll just rebuild the Jenkins based on your configuration. So, one important piece here is the slaves as I was talking about. So, currently, to have a slave, what does it mean in Jenkins world? You need to have an Docker image that has Java on it, right? So, you can run this JNLP Java agent. By the way, if somebody in this room go ahead and rewrite this to go or something sane that we can run without installing Java, I will send him t-shirt personally. Sign it, you know? So, what this template... So, we have a special template that basically converts every builder image, which means in OpenShift terminology every image that builds your source code into a valid Jenkins slave. So, yeah, that sounds nice. What we really do is that we install Java on that image, nothing else. And we also install one shell script that will then act as a connector to the Jenkins. So, what really happens is that the Jenkins starts a pod, which starts a container, which runs your builder, and that builder will launch a shell script that will download the agent from Jenkins and start it and connect to Jenkins, right? So, you can then, from the Jenkins, you can execute the shell script on that slave and you can build your application, execute unit tests, execute whatever. If that is done, Kubernetes automatically puts the pod down. So, you know, it's not consuming any resources. What is important, as I said, is that you are creating slaves on demand.  So, you create a pool and you say, Kubernetes can launch 30 slaves in parallel, right?  Next slide. Other way around. And this is Ari. So, hi, I'm Ari Labigny. I got my mic right here. Can you hear me? So, another part to this is you can manage your jobs. You can have all Jenkins jobs, if you were to go under the covers of the UI, are basically in XML files, which we actually have in our example repo right now, but some better way to manage an abundant amount of jobs. So, if you had a lot of microservices, you had a lot of these applications that you're testing and you wanted to kind of run through a set of jobs, an easier way to do this is to use Jenkins Job Builder. It's a nice YAML template. You can basically, it has a templating system that allows you to define many jobs in a very limited amount of YAML. You can use this notion of defaults that allows you to reference them and reuse a lot of the same data instead of having to have all this XML code and duplication of XML code and names and things like that. You can just reference it. You know, it reduces the redundancy and it can easily be uploaded into the Jenkins system. And you're maintaining YAML, which is very easy to read as opposed to XML. And you can put all this under source control management and it's much easier to manage. That's another piece that we added into this kind of CICD workflow. Just to also mention, Jenkins Job Builder is an upstream open-stack project. It's very extensible as well and you can contribute to it. So, we wanted to show before we go into the demo is kind of the picture of what this workflow looks like. So, as Miquel mentioned, we have a test phase where we're running it. These basically break down to the Jenkins jobs that you're going to see in the demo. And we have a test job that will spin up the slave, the slave pod that in Kubernetes, as Miquel indicated, when that starts, we can do some level of testing on that pod, which will be a Jenkins slave and destroy the pod. Now, in the example we're showing, it's a sample app, so it's just one container, but there's no reason this could be multiple containers that we're going to run and validate and test in that phase. If that is successful, we get an automatic promotion using the promotion plugin to then kick a build. Now, this is not a Jenkins build. This is building in actually the open-shift environment and kicking that off in a namespace called Stage or a project called Stage. Once that's done and it was successful, that build is successful, you could do this automatically, but we chose to actually take a manual approach of you can then deploy this in your Stage namespace. You can think of it as a company that has a Stage environment that they're testing out an application and they want to test that out and deploy it. In real life, you don't deploy to Stage every single commit you make to the source control version. That will be just crazy. The QA and testers will hate you for that. Usually, you have some testing lifecycle where you say this is the version we want to deploy to Stage and we want to have a QA or testers spend one week on it and tell us if it's good or not. You don't want to automatic promotion to Stage every time you have a new image. I would say the opportunity for integration testing. You may have a test environment where you can do integrate type testing before it goes to Stage. There's nothing preventing you to have a pre-Stage or something like that where you do all this evaluation. Our sample really shows these four, but there's no reason why you could have another pipeline in there as well if you wanted to expand that or you wanted to be more cautious in what you're rolling out. Then the other idea is you would then, once you're successful in your integration testing, you would manually promote to the production name space or project and then you would deploy your application and everyone would be happy. Your new tested application is out there in the world to use for your end users. What is important here is the connection to OpenShift which allows you to set different policies for staging and for production here so you can have people that can work only on stage, you can have people that can touch the production. Those two people don't talk to each other. In the real world, usually they are the same people, but in some companies, you have these security policies in place, so OpenShift really allows you to do this scenario because you have a separation of privileges between two projects. So I think we're ready now to show the demo. So the reason why we play a video here and we are cheating is that the conference Wi-Fi really sucks and we need to download like two gigabytes of Docker images and I spent like three hours trying them to download them and that failed, so that's why we play the video, but it works the same. Yeah, the other thing to note too while Kale's getting that set up is all this is in, at the end we'll have a list of references. You can just go get this project off of GitHub and use it.  So this is the OpenShift console. It's not that green in real life, it's white. And yeah, so this is the OpenShift V3. So basically what are we going to show you is starting from nothing. I mean like literally empty projects, so I just have the projects created, which is the CI prod and stage. You can see the projects there and there is nothing in those projects. Like they're completely empty. So I'm going to show you how you can, in eight minutes, you know, and maybe now it's even faster because we fix one plugin, so it's like five minutes. You can get from nothing to have the full CDCI flow for your single application. It's really easy now. The key thing too is there's, the communication between Jenkins and OpenShift is done through an OpenShift pipeline plugin that was developed so that it's two can talk together. Yeah, so now I'm going to create the Jenkins slave image from my Ruby 2.2 image. So this will be a Ruby application because, you know, Ruby. And, you know, I'm just going to build the slave image using the template I was describing. So here basically I set the image stream name, so I want to use Ruby 2.2 Center 7 and want to convert it to the Jenkins slave. So, yeah, that's the name of the image stream. You can also specify, like, an alternative repository, where you have your customized build script. So if you want to add something more than the slave stuff, like, you can also add more, like, testing libraries or something like that. So we just hit create. Yeah, there's nothing. Because it's just the build. It's nothing else. It will just produce the slave image. So now I'm going to create the Jenkins server. So I'm going to create the Jenkins master. And, yeah, so for the Jenkins master, you can specify the service name. So that's useful when you want to run something more than Jenkins and you want to talk to Jenkins service within your pods or within your application. You can specify the Jenkins password, which is the admin password for Jenkins. You can specify alternative Jenkins image. So if you don't want to use our image, you can specify whatever image you want. And then the S2I repo, that's the thing I was talking about. That repository contains all the configuration, plugins, jobs, basically, you know. And this is fully customizable. So if you wanted to add your own plugins, like, we've downloaded all the plugins into our example. You could also have a text file that has a name and a version. And maybe you wanted to go to a different update site than the Jenkins update site. You could do all that and customize Jenkins the way you want using that template. So now I deployed the Jenkins. So now the Jenkins master image is currently being built. So I can view the logs from this build. I hope I will show that. I don't remember if I... This is from the slave. This is from the slave. So what really is happening here is that you can see we're doing yum install Java and then this is a wrapper, nothing else. And now you can see the highlighted. Back to the builds. So you can see we copy the repository files. We install 141 Jenkins plugins because Ari really likes to have a rich Jenkins. And we remove the sample Jenkins jobs that comes from the original image and we install our own configuration. We push it to the internal registry in OpenShift and that will basically cause the Jenkins to be deployed automatically. So now you can see I have a... I have one pot of Jenkins running and I have the route bind to that pot. These small buttons, I think you will see that later on the OpenShift presentation can be used for scaling up and scaling down. So if you want to have more Jenkins running, you can just hit the button. It doesn't work with this Jenkins image. So now we just go to Jenkins. Yeah, I have cell sign certificate. Yeah, and it's still coming up. But then once you'll see the Jenkins service went up. So you can see what's really going on in the Jenkins. So it's copying the configuration that takes password change, setting a password. It is automatically discovering the images for slaves. So the Jenkins will be pre-configured with those images. And it also downloading the Jenkins job builder, which is a Python project. This is the kind of customization you can do on the official Jenkins image. So if you want to install more stuff, you can just write your own shell script that will do that. And Jenkins is now getting up. And now you'll see the flow that we showed before. You'll see the four jobs in there to get reflects the same flow. So it's up. So I use the password I set in template. Yeah, and this is the screen. So all these four jobs are the jobs that I pre-configure. So I put the XML files there. I can use the Jenkins job builder to automatically create those if I want. So this is on the bottom. You can see the test. I think it's barely visible, but it's called test. Then you have a build here. And then you have a deploy stage here. And then you have a deploy to production. So Jenkins finished. So now what I want to show you is what I already spoiled, which is that the Jenkins will automatically be configured to have the slave images, like the Kubernetes configuration already done here. Yeah, so the credentials will be set. The image stream will be set. The Docker image repository will be set for you. Everything will be pre-configured. The Kubernetes plugin we are using here is done by Google. So it's a Google Jenkins plugin. It's an official plugin for Kubernetes. So now I kick the test. So I don't push the source code, but I can configure it to trigger on the new committed master. So I trigger it manually. So you see that the job is now in queue. And now we will just wait till Jenkins tell Kubernetes to spawn a pod. It's running. It's taking some time because when the Jenkins starts, it's still not finished with initializing all the plugins we have. So it takes some time to download all the crab and metadata and everything. And after that, it will start operating reasonably. So yeah, it just sits here in this queue state waiting for that slave to show up. And then now it's starting to come online. So you can see that this is the pod in OpenShift. So it started the slave automatically. And in the second, the job should be assigned to the slave. And you will see the console. Yeah, you can also tell up here that that's running on the slave. The other ones are running on the master. So this is the log. So you can see here. It's building remotely on this crazy name slave. It's running inside the Ruby 227 image. So what this job is really doing is it gets the source code and installed all the dependency and execute rake test. So it will just execute the one unit test. So we can prove that you can do testing here. That was tribute to Jenkins developer. And no, yeah. So now the test job is done. And you can see the build job was automatically started. So now we are building the image in OpenShift. So if you go back to OpenShift and go to stage, you can see that the image for sample app is currently being built. It's a Ruby app, so OpenShift will build your application and push it to the registry. And the next step is that you have to deploy it to stage. And this is the bug we found when we were recording this demo. So the build is now trying to make sure that the application was built and is deployed. But in this case, we are not deploying it. So it will just hang for two minutes. So the old version, that's been fixed. This was fixed last week, so super fast. I'll just skip this. So right now, since we had the automatic promotion from test to build, once that's done, then we will, right now it's doing the build. So that was successful in OpenShift. And now we'll manually, and you can see the promotion status plug in there. I'll see the console. And now we'll manually deploy in OpenShift to the stage project. And there it goes. So now you can see in the sample app, it's been deployed out into the stage project up top. You can see the stage project, and we've deployed it, and that's ready to go. Yeah, so I mean like the deploying to production works the same, so you kick the job, and it will deploy the same image to production. So how this is working, actually, in OpenShift, is that we built the Docker image in stage, and it's in registry. So what you can do in OpenShift now is that you can tag the image from one registry to one repository to another. So in OpenShift, every project has its own repository. In this case, you have the stage repository in Docker registry, and you have a prod repository in Docker registry. So to do the promotion, basically, that means that you run oc tag, stage slash, sample app, latest, or whatever Docker image you want to promote, to prod slash, sample app, something, right? And that will basically move, it will link the image from stage to prod. And in prod, you have a deployment config that is configured to trigger deployment automatically if there is a new image. It will automatically deploy your application. I think that's it. We can flip to the slides. That's basically the whole pipeline showing in Jenkins and OpenShift and that connection.  So this was a really simple example when we have just one application that has just one source of source code, so it's a really simple Ruby application. But in the real world, what we expect from people to build is the application that consists from 10, 20, 50 different microservices, and all these microservices will be deployed as containers, or as their own services inside OpenShift, and they will talk each other and provide the application itself. So I know that marketing hates to call it an application, but we call it application now. And, you know, so what this is really useful for, if you have this scenario where you have different services and you need to make sure they all talk each other and they work each other, you really need to have something like a CICD flow. Otherwise, you will just shoot yourself after some time, because it depends. If one container gets broken, that can mean your whole application is broken. So it's really important to test the whole deployment for us, like the end-to-end testing, the whole thing testing, and then promote the thing that works and was verified by the QA, the testers, or whoever to production. And what Docker really allows us here, we are not working only with the source code now.  That's not longer true. Now you can promote this Docker image that has the application built from this commit, which what really brings us is that you promote the whole environment, the whole operation system, everything, you know, as the thing that you are going to promote to production. So it's not just the single source code commit, it's the whole environment. So that's what Docker allows us to do now. Yeah, so in conclusion, it should be fairly easy to take what we've done in this example repo and create your own CICD pipeline. This plugin and this feature should show up in release 3.3 of OpenShift, which I think is about the summit timeframe or something like that. And some things that we'd like to add or I'd like to add is the delivery pipelines or more of a visualization in Jenkins of the whole flow. So we can see kind of what OpenShift shows graphically, but it would be great to see that kind of pipeline. So I think it would be great to have this view, you know, like icons and stuff moving around. Nice and pretty. And then there's some features to add to JJB, which I'd like to work on just to extend the promotion plugin, because there's some options that aren't available today through that. And I think that's it. We're open for questions, please. Yeah, we really want to... Hold on, one sentence, one final word. So what we are looking for is that I know that a lot of you will not ask questions now because you are shy and there's a lot of people here. So we really want to talk with people about what are the use cases, what are they trying to build, so we can make this stuff really helpful for them.  So... Yeah, and now you can ask questions. Builder test. Like, how do you map a project to an image like if it needs a specific environment to test in? So the builder image I used to convert to slave, that can be whatever image. You can define whatever image you want there. So it can be your custom image, it can be whatever image. It doesn't need to be the official OpenShift image or something like that. So the template I was showing on the demo, it has this image name or something like that in it, right? So it was a ruby-22-centus7. So that's the name of the image stream that exists in OpenShift. So if you create your own builder image and create your image stream, you can just use that name there, and it should work. So one of the patterns that I've been interested in is like containerizing your test suite, and then making that a slave through that mechanism.  So it's an interesting pattern that can be extended. However, yeah. Who else? Guys, sorry if you covered this. You know, maybe, how is it similar to what Fabric8 is doing or what the ManageIQ is doing? Can you find any similarities or differences? Yeah, that's a good question. I mean, Fabric8 is also putting something together that's similar, but I think they have some specific use cases when it comes to Java applications. I don't know if they're... This is more, I think, a general use for any type of application, and that's what we were going for, is to make it as general as possible. They also use, I think, the workflow plugin in Jenkins to accommodate some of this. And the front end to that is basically like a groovy file that people really have to learn how to use. And that's, I think, where JJB is a little bit... It gives you some benefits, it's a lot clearer to follow. Yeah, I think there are two problems that we are trying to solve. The Fabric8 guys are trying to create really first-class Jenkins CDCI experience for Java, JBLS applications or Java-based applications, which is a great goal. I mean, they're doing a great job doing that and their demos are awesome. The problem is that we want to make this more generic with other people, right? So if you don't write, like, if you don't use Maven or you don't use JBLS or, you know, you want to build a Ruby application or Node.js application or Python application, we don't care what builder you have. So we want to provide the pieces of the legal to people and they can then use it to construct their flows, basically. So how many IQ is fitting here? I don't know really exactly how this... So what many IQ is, it's really CloudForms 2, which is the tool that you can use to manage or orchestrate the whole cluster for... So there's one level on top. So you're sitting there and monitoring all the nodes that OpenShift is using, getting informations from them, collecting data, creating all these charts and managers, views and so on. So you know what's going on in OpenShift in the cluster, but it's not really like something that's related to the applications or building the applications, you know, from developers. One more question? I'm not going there, so you need to scream. We know about that. So this is a very common question. So in OpenShift builds, you have some concept called incremental builds where you can... If you already built something and that image exists on the node, we will reuse that image so we don't download the whole internet over and over. We know that there is a limitation. If you have multiple nodes, one from one node to another, that's one case. So it slowed down the build as well.  You're either going to download all the dependencies from Maven, or you're going to download the entire Docker image that you built previously. So the answer to this could be use one Docker registry that has shared storage across the cluster. That's one answer for me. Another answer is that we recently added Docker source input to the build. So you can specify a Docker image that we pull and suck the artifacts out of it and put it into the build. Thank you. You are out of time. You can continue the discussion. Thanks a lot, guys. Thank you. Are you a speaker? No, I'm not. I could be. I have another question. Sure.


How to find out more about your exams? When the exam timetable is released, an email will be sent to your student email address, notifying you. You can then check your exam timetable on the exam's webpage or through student services online if that takes you fancy. If you see that you've got two exams at the same time, then check your student email. The exam's office will email you with different arrangements for your exams. You can't be in two places at once. Even if you invent that cloning machine that you're working on, for your thesis, it won't work. Don't do it. A day before each of your exams, you'll receive an email reminder at your student email address. Make sure you've updated your mobile number so the university can send your text with your exam, exam time and the exam room.


So, today, I'll be talking about synthetic monitoring, what it is, why do you need it and how do you want to do it, you know, like the basics to, you know, how to get it implemented at your organization. So who am I? I'm Suraj, I'm working on Grafana Cloud these days for past one year-ish. I've been busy building synthetic monitoring product for Grafana Cloud.  So that's who I am. So let's just define, you know, what is synthetic monitoring. So we all have monitoring on our systems, right?  And we alert on that. But we, like most organizations don't really know how applications are doing from their users point of view, you know, are users in certain locations, seeing degraded performance, right? Your internal monitoring will say, say everything is fine, things are running as expected, you would not know these things unless you monitor things from your users point of view. So that's synthetic monitoring, you test externally visible behavior as your users would see it, you know, and if you have users all over the globe, you would need to monitor all over the globe. Like also synthetic monitoring is part of this, you know, broader black box monitoring category. So sometimes we will also refer to it as black box monitoring. But like in this talk, we'll just call it synthetic monitoring. So quick question, I just wanted to ask everyone, you know, like how many folks here have used synthetic monitoring or are familiar with synthetic monitoring. So feel free to, you know, unmute yourself and let me know if you use synthetic monitoring and if yes, which product do you use? I heard Cisco uses black box exporter in the last talk. We mostly use, it used to be a run scope, we are migrating towards neural network. I see, nice. Any other folks who are here who use synthetic monitoring already? So I guess it's not as common as, you know, other monitoring practices, right? So why do we need synthetic monitoring? Right? As we said, we want to find out how our application is doing from our users point of view. So to truly find out how our application is doing from users point of view, we actually need to pretend as if we are users and then test our applications as if our users are using it, right? And if our users are all over the globe, we would use it from all over the globe. So I want to share a personal story of mine, you know, like I made a change that broke production for four plus hours and we didn't even notice that production was broken for four plus hours. And the change that I made was, I added a route in load balancer to, you know, redirect traffic to our new website. So, you know, fairly small change. Nobody thought it would impact production, but I don't know how, you know, I still don't understand. I think it was something on like Google's load balancer UI that I did. But because of that change, actual production traffic was also ended up going to your website. We didn't notice it until late that evening. It was 11 p.m. and we had a scheduled maintenance. We started doing scheduled maintenance and then we found out that, you know, we cannot really use our production application. It was down and it was returning, you know, errors. And things were all fine from your inside, you know, servers or databases were all good. So what actually happened was, you know, our actual production traffic was being routed to Netlify because that's where we had our website. And I looked through header and I saw an X Netlify header. And that's when I found out that, oh, should we be messed up, right? And then we fixed it. Like even if, assuming we didn't have that maintenance window, things would have gone for longer and customers would have been impacted. But yeah, that's how I took down production for four hours and didn't knew it. Production is down. I mean, we also had instances where our monitoring went down and in those scenarios, like during an outage monitoring went down and we didn't have anyone alerting, right? Like nobody told us that our own, like customers told us instead of our monitoring systems. So that's not a good state to be in. Also, assuming you have, you know, regional deployments, right? You have configuration that apply to certain, like certain configuration apply to certain regions. Let's say you do a deployment and your team is sitting in one region developing and deploying, like deploying globally and things are only broken in that region. It would be really hard to know that because from your point of view, from your region, things are all fine, you can use your application, but customers in that region would either see your application broken or integrated performance. There was one such incident that happened with folks at K6.io. So Daniel is SRE at K6.io and K6 recently joined Grafana Labs. So I was talking to him about K6 and synthetic monitoring and here is what he said. So they misconfigured CloudFront and because of that, they had a reasonable caching issue. You know, nothing major, things were slow in one region and they wouldn't have found it because there was no way to find it, you know, because folks in other regions were seeing it all fine. But because of synthetic monitoring, they saw the response times and latencies were up in batteries and then they hand down and fixed it. So it's not just me who breaks things, like it's almost all of us. So another question that I want to answer is how to do synthetic monitoring, right? We talked about we want to monitor from our users point of view, we want to monitor from users point of view.  So even if you, let's say, like, use Google and you set up your infrastructure on Google and you use Google to set up another monitoring, then you would still be, you know, going through Google network, unless you tell Google to not go through Google network. So it's a bit tricky to actually go through internet if you are not going out of that cloud provider. So, you know, because Google has its own optimized routes and whatnot, they do their own networking magic to make things fast and try not to leave their own network. So that's also another important thing when you want to do synthetic monitoring, right? Because you want to make sure that you're actually coming through regular internet where your users are coming through. So another is exactly how to do it. So there are two options. One is you can do it yourself, you know, Blackbox Exporter is popular project in Prometheus ecosystem. So if you have Prometheus, you would want to configure and deploy Blackbox Exporter at locations where you want to monitor your applications from. And also you have to be extra careful about the networking magic that other big cloud providers does. So you have to actually leave your cloud provider and deploy it on other cloud provider that you don't use. There is one more project from Google. I think it's called Cloud Prober. I have never used it, but supposed to be used for, you know, Blackbox monitoring synthetic monitoring. Or, and then there is always Chrome jobs. So you can write Chrome jobs to ping your websites and monitor them, but that's not really scalable and easy to manage. Also, there is a trade off, you know, there are certain pros of doing it yourself and then there are some downsides of doing it yourself, right? Like when you do things yourself, you have full control over what data to collect, you know, where to store it, how to format it and whatnot, right? Like you can do whatever you want. You don't have to start from scratch. There are existing open source tools, right? Blackbox Exporter is there, but I'm pretty sure there are others as well that can do based on, you know, how you want to monitor what you want to monitor and whatnot. But the downside that is that now you need to monitor this service, right? Now you need to maintain this service. And let's say you have, you know, certain assets like in marketing websites and whatnot. Then people who are not, you know, engineering savvy would have to go through the engineering to get their services monitored and, you know, have their checks up and running and, you know, modify those checks as well. So that could be seen as a pro and could be seen as a downside because now you have one more hop and, you know, engineering have to be involved. So yeah, and again, the meta monitoring question comes in, right?  And as you I said, it's turtles all the way down, right? So, so another solution that you have is you use a managed service. It's easy to use no engineering overhead. Most managed services have a nice UI where people can just, you know, put an URL or endpoint and they would start monitoring it. They have a global locations you can select where you want to monitor your applications from and then they'll take care of the rest, right? You don't have to worry about operating it and then monitoring it and then again, meta monitoring it. They like, there is also another downside of that, you know, they might not have locations that you want, right? Some have, let's say you want to monitor your application from a location where they don't offer their pro, right? And there is no way to gather data from that location, right? Also, most, you know, managed services don't mix well with your existing white box monitoring, right? So you have all of your internal data, but then, you know, let's say you use an managed service. So that service will have its own UI, its own way to look at data. So people will have to learn how to use that service, you know, learn how to get data out of that service. And then, like, it's not easy to mix with your existing data. Let's say you're using Grafana and then there is, like, you can set up things to get your data along with your other data, but again, it's work.  You don't want to monitor them out from outside your monitor, but you just want to make sure that they are, you know, things like VPNs and whatnot and things that are critical for your organization, you know, because almost every organization have internal applications that are not public, per se. So the only way to reach those applications would be to be in your network and not every managed service offers that. So that's managed services for you. So now instead of, you know, going over all the managed services and all the open source solutions, I would just talk about, you know, what we have at Grafana Cloud, because that's what I've been building for a past year or so. So Grafana Cloud Synthetic Monitoring looks something like this.  But, you know, people who know Grafana might say, wait, wasn't it called, you know, world ping, didn't you guys have guys had one more service that did exactly the same? Then you would be correct, you know, there was a service, you know, was because it's already EOL last April. And right now it's on read only mode and will be taken offline on August 1st. So world ping was the very first service from Grafana Labs. That time Grafana Labs was called Rain Tank.  And this world ping product was using Grafite as its data format.  And then it would gather metrics and then store it in Grafite format.  You can throw in labels and, you know, like two or a bunch of things with it. Also, Prometheus is very powerful. So Grafite was like, we were feeling like, you know, we could make it better, but because of Grafite we couldn't. So we decided to duplicate world ping and then move forward with the world and, you know, move to Prometheus-based world. Also, another, you know, major requested feature was, let's say you have a check running from, you know, a remote location. And only that location is failing. And there were no logs as part of all ping service, you know, like your checks would generate logs, but then we would, like there was no feature to show those logs to you, right? So customer would have to either, you know, create a VM or, you know, like use a VPN to browse services from that location and then debug that. And that was, you know, suboptimal and painful, you know, we don't want to do that now. So logs was another, you know, major missing feature of world ping. So like this is what it was. So 2015 world ping came out 2016, like it came inside, 2016 it came inside Grafana was an app plugin. And then like today we moved on from world ping and shut down world ping and have developed synthetic monitoring that is same product, but different, new and better in various ways. So if you want to know more about, you know, what is different from world ping and, you know, what's new in synthetic monitoring, my colleague Teddy wrote a blog post about that. I have new links to this slide. You can go to this blog post and then read more about the exact product differences that are there. So, you know, why new products? The world is moving to Prometheus, you know, almost everybody is adopting Prometheus. All major vendors support Prometheus ingestion, Prometheus querying. So we also wanted to, you know, move with the world and have Prometheus based metrics for your synthetic monitoring data. Also, the logs that I mentioned, right, we want logs, we want, we don't want our, you know, customers to have to connect through a VPN and then try to reproduce a problem that our probe is seeing, right.  So new synthetic monitoring products, products have logs. And also, like, because it is built on top of Blackbox Exporter, we have all the configuration flexibility that you get with Blackbox Exporter, right. We expose all the configuration options. Also, Blackbox Exporter exports Prometheus metrics. So because of that, our synthetic monitoring product also has Prometheus metrics and we integrate well with our Grafana cloud offerings. So, you know, like metrics are stored as Prometheus metrics in your Grafana cloud hosted metrics instance and logs are stored in your hosted low-key instance. So if you want to mix and match with your other data that you have in the hosted metrics and hosted logs instance, that would work out of box without any pain, you know, like you don't have to feed in data, collect data, get the data around and, you know, worry about it. It's already there. Also, it is inside Grafana. You don't have to use another tool. You don't have to teach people to use another tool. It's all Grafana and Prometheus. And it integrates well with cloud alerting. So Grafana has cloud alerting product. It's a hosted alert manager offering. So if you can actually use the same alerting infrastructure that you have, right, infrastructure to manage your alerts, manage your routes, manage your rotations, you could just use the same thing for your synthetic monitoring. You don't have to go to another product, add people to it and then configure email alerts, you know. And because it is an alert manager, you get all the great things that alert manager has to offer, you know, including places where you want to get alerted from, you know, like be it PagerDuty, email, Slack, Telegram, whatnot. So yeah, another bit that we have in new product is private probe, right? So private probes are probes that you can run in locations where we don't have our probes or inside your internal networks if you want to probe your internal applications. So private probes, like you give it a token, bring it up, then it would connect to our API, get all the work that it needs to do and start doing it works and collect metrics and logs from the checks that it executes and then pushes them right back to our cloud. So you just need to run a process. That's it. And if you want to run a Docker container, we also have that. And I'm assuming almost every organization can now throw in a Docker container somewhere, right? And if not, you know, we also have other ways to install. So I want to do a live demo right now. So all hail demo gods. Yeah, there we go. So I have synthetic monitoring installed in my personal Gryphana cloud instance. You can see it like that's the icon. Let's go to the home.  So this is last three hours. So I see I have, it supports DNS, SVTPA, DCP, and ping checks. I don't have any ping checks. So that's why it's only showing three of them. And then it has all the regions where we want to run it. So there is an instance for my DNS check. So I'm doing a DNS check on my website. And it says reachability 99.8% and latency up and bottom up. These are my, you know, STTP check. And this is my TCP check. So let's look at the UI. Let's go through and create a check. So this is the UI where you see your created checks. You want to see a compact view. You can see how many locations it's running from, you know, what's the frequency, how many active series it will generate. We don't build on your check executions. We build on the data that you generate in store. So there is no separate billing for synthetic monitoring. You don't have to worry about, you know, how often I'm checking. If you generate more data, you'll get bill more. And if you generate less data, you'll be billed less.   Also, there is this new, you know, visualization view if you want to look at your checks at a glance. So I see like these two checks are failing. This is successful. This is successful. Okay, so let's go ahead and create a check. So these are four check types that I can create. I have to define a job name. So whatever you write will be sent as a job label in your promises metrics. So let's monitor Google because why not?  Let's see, you know, like where I want to monitor them. So all these are, you know, hosted probes and this is my private probe. I'll go over to private probes later. I'll show you how to set one yourself. I'm running this on my laptop right now. And it's executing checks and sending data. So I'll select all of them. I want to run it every 60 seconds. I'm out after three seconds. So we, there is this button.  So we only, you know, like they are useful, but, you know, if you run tons of checks and if you are not using those extended metrics then you would end up paying more. So like if you want to only look at basic metrics, you can just leave this and check. But if you care about all the metrics that Black OX Exporter has to offer, you can check this and then you'll get all the metrics.  And then if you have a bearer token, basic authorization thing, so you can put your bearer token inside here or have your username password if your service is behind authentication. You can do validation HTTP versions also and see, like check for ourselves. Also do a regular expiration match on your headers and body. Like all this is already there in Black OX Exporter, this UI makes it easy to configure and you know, intuitive. So people don't have to write Black OX Exporter configuration. You can add labels to your checks. So they will show up in your metrics and logs. So let's say you have a team label, team Google and then, you know, you can use them however you want. Also we have an IP version selection let's say you only want to monitor through IPv6 or, you know, let's say you don't really care about this. And we have built-in alerts that are like, you can use this and then configure default alerts based on, you know, your time and reachability. So, and those alerts will be there in Grafana Cloud Alert. So let's go ahead and save this check. Okay, showing any because it's not running yet, it'll take a while to go and, you know, start generating data. So these are all the probes that we have been running for you, like you can go to like, see, okay, this is public. That means that, you know, this probe is hosted by us and you can run your checks there. There is also a private probe that I'm running. So this is my private probe that I'm running on my laptop. It says online, you know, I'll go ahead and kill it and then it'll show up offline. So it is offline, you know, let's bring it online again. So we have synthetic monitoring agent on our GitHub. So whatever code that I'm running as private probe is actually open. So you can go and look at the code if you want. The code is that GitHub, Grafano, synthetic monitoring agent. So that's what I'm running, like I'm not running some random code that, you know, you don't want to run on your network. Should show up online. Okay, so it is online. The success rate here is, you know, the amount of checks that succeeded on this probe and then there is this alert. So like, if you know how to configure ProMitch's alert manager and if you want to configure your own alerts, then like you can leave this alone. But let's say you don't want to mess around with the synthetic monitoring metrics that we generated. You just want basic checks on, you know, let's say if my service falls below 95% or 90% or whatnot for five minutes, then you can just save alert and then this would generate an alert manager rule in your Grafano Cloud alerting service. Same for other services. And if you remember in check creation, there was an alert sensitivities feature. So like we add low, medium and high label in your checks. If you configure that, then you can target those checks here. So these are three default alerts that we add for you. So let me go ahead and show those alerts. I'll go to the cloud alerting product. And if you see, this is alerting UI that is for Grafano Cloud alerting. It's, think of it as a hosted alert manager because it is alert manager, you know. This is alert manager configuration. You have silences, you have notifications and you have your rules. So there is one rule that I created, you know, website is slow. So if my website takes less than five second, I'll alert for greater than five seconds for five minutes. And I'll say my website is slow. This is what I have created. And these are the default alerting rules that are part of synthetic monitoring. And then we create this recording rule for you. So you don't have to type the same query again and again. So, yeah. I'll go ahead and, so we import five dashboards, five default dashboards as part of synthetic monitoring. So like we already looked at summary dashboard, right? But there is a dedicated dashboard for each check type. So there's a dashboard for DNS, Bing, HTTP and they are your normal dashboards.  Put them in a folder. So let's look at the DNS dashboard. Let's see what's happening with my DNS queries, right? So look at DNS, it says Bangalore 3.57 percent. So it says uptime 100 percent, reachability 99.83 percent. So uptime means that only like at least one probe is able to reach your service and confirm that your service is up. And reachability means, you know, the overall combined ability to reach all these probes. So let's say if one probe is not able to reach or if it's getting error, then reachability will start decreasing. That means that you're not really reachable in certain locations. Let's see records, what not. And this is the logs. So you see that there are some errors coming from, you know, Bangalore probe. And you can see what happened. So it says error while sending a DNS query, your timeout, like really helpful when you want to develop something. So it says beginning check timeout. So it says check failed, duration five seconds. Okay, check failed duration five seconds. So that means if I go ahead and look at the check. So this is our check, right? I configured five second timeout, right? So like if it takes more than five seconds, I'll consider this check as failed. I'll run this every five seconds. Go ahead and increase and decrease this based on my threshold. But yeah, let's look at the HTTP dashboard that we have for our HTTP services.  So let's look at the Google check that we added just now. So this is our Google check. We see, you know, it's up, but it's not really reachable. Could be because of our threshold, but you can debug, right? Why it's failing? You have all the logs from your checks and these are your normal look logs. You can go ahead, explore on them, and then all the log queue that you want. Let's say I want to show me all the errors. I'm not a log queue expert for, right? Bad log queue, but whatever, you know. So it's cannot assign requested headers, okay? Again, I can go ahead and do show context, that TCP cannot assign, making a strict request, resolved, targeted, whatever. So there is some issue, like you have the logs to debug it, right? Whatever, you know. And, you know, let's say you have, it shows SSLX query, right? So you can alert an SSL also, so. I'm assuming almost every service offers that, but I just wanted to show that you also have this. And in the response, let's say you get a breakdown by, you know, how much time? So if you look at this, majority of time is going in resolve, and then the check actually fails. So that's why the other metrics are zero. But let's look at my website and see, you know, what's going on. So you can see that, you know, my home network is not as quick as, you know, other probes, so it's slow from my point of view. It's fast when we look at the reptilian and Bangalore problem. So this is what I mean when I say, you know, network is not uniform. So you have to actually monitor from all over the world and go through actual internet.  What not? These are the probes. You can see what version you have and what not. Anyway, I guess that's all with the demo. I wanted to tease it out and, you know, say what's next as part of synthetic monitoring. So we are in the process of, you know, planning and building trace route feature in it to trace how, you know, Atlanta probe is reaching to your service. You should be able to run trace routes from our probes. Once we have this live, you will be able to run trace out and look at the data and, you know, visualize it and see how it travels all over the internet. Particularly useful for folks who want to do network monitoring and smoke ping. So the current ping feature that we have, it only sends one pin packet, but that's not really good when you want to, you know, monitor your response latency. So smoke ping would send a burst of things and then you can look at the data and see how it's doing compared to a single packet. Though no promises on when these things will be out, but hopefully they'll be, they'll be out soon. So, okay. So now let's say you say, you know, looks neat. How do I get it? You know, I want to use it to monitor my home lab. I want to use it to monitor my personal project. So Grafana Cloud has a free tier without any credit card or anything. You can just go sign up and use all the Grafana Cloud features including synthetic monitoring. So you have met its large spaces alerting and it's more than enough to monitor, you know, site projects, home labs and personal projects. And even if you want to play around with alerting tools, observability tools and learn things, you can go ahead and use our free tier, learn things, play around with Grafana and from its ecosystem. Grafite is also there, but I'm assuming nobody wants to learn Grafite these days. That's all from my side. Thank you, everyone. These slides will be available, I'm assuming on the Hasgeek platform as well. And if you want, you can go to my website and download these slides as well. I'm there on the internet. You can reach out to me on Twitter, write an email, my email address is there on my website. But yeah, so I'll stop sharing and we'll go ahead with the questions. Yeah, I mean, of course the last slide kind of got to me. I was, anytime this feature is coming to the open source integration. Like see, the probe is open source already. So is there a way to set up my personal open source probes across multiple other clouds? Let's say I'm hosted on AWS, I can probe in either error code, data lotion, GCP, wherever. But Grafana, I'll still live with Grafana Cloud. I don't have this feature on my self-hosted platform. So is that anywhere in the product pipeline? So in the last couple of months, we were busy with deprecating world thing and migrating those users off. So we were only focused on the cloud as a data storage because that's what we needed from an organizational product point of view. So that's what we have. As of now, that's not there on the roadmap because we have a free tier. So people say, oh, I want to play around with it. Then we just say, free tier is more than enough. We have 15K active series that are allowed. Also alert rules and logs are there. And synthetic monitoring, if you look at the checks, we tell how many active series it will generate, right? So some, like you can monitor hundreds of endpoints of synthetic monitoring with free tier. Let's say you have, like there is one part that you can do. Let's say you have your local Grafana and you want to install synthetic monitoring. You can configure cloud as a storage destination, install synthetic monitoring plugin on your local Grafana and provision those cloud data sources in your local Grafana and synthetic monitoring will work on your local Grafana. You throw the cloud once. Yeah. So it will collect data sent to cloud, but you can use it. In fact, it will work on your site. Yeah. Still seems around about we, but I'm pretty sure with Grafana track recording near future, we will be able to see this integrated with the open source version, but fingers crossed from my side with this. Other than that, like if I want to do this at my org right now, we do have a very distributed customer set. Then I'll have to go for the black box exporter route, I think, and set up custom pros to that, right? Yeah. As of now, if you want to store data on your own and store logs on your own, then I think black box exporter is the way, but I would say like, even if you have your own internal cortex and other services, you can still use free tier just for this. Install it in your local Grafana, provision those cloud data sources, then mix it and match it with your in-house data and then just check it out. I don't have any other questions, the whole thing looks pretty simple enough. I have used, I think, black box exporter once, we were back in only one of the orgs that are working, but that also is for just a simple cool system pink test, not a distributed test across everything. We just went monitoring our external info from one location, not quite all locations possible. But let's wait for anyone else from the audience to pitch in with questions, because this is definitely a super interesting topic, personally for me. So anyone else has questions on this? Yes, Suresh, this is Ashok here. So very interesting. We have used black box exporter extensively, use it all the way from SSH chat to ping and everything else. That's our easiest way of finding, okay, something is up on the availability front. So one question I had was, see, when we do it, at least currently, when we do it the cloud way, what are your thoughts on the latencies? Because I have to go back to cloud and then come back, then measure something bit. No, no, no, no. So cloud is where you store your data, right? So the checks are executed all over the world. No, I agree. What I'm trying to say is, since I'm storing the latest data, might not actually be the latest. Oh, okay. I might not get the real-time data. Oh, okay. So I think the latency should be fine. We have, I think two regions as of now in Gryffana cloud. I'm not sure if you can choose your region in the free tier, but... I think it will get better over time as joy, sir. Yeah. So I would say give it a go, install on your Gryffana, like play around with it and see how is the latency. Shouldn't be a problem, you know, from what I think. Yeah, in our space, like enterprise, pushing anything to cloud is forbidden. So yeah, we'll try another one. I see. And it's also not about just enterprise. I think most orgs, even if they are not enterprise, posting their own Gryffana and... It's a pretty standard pipeline, right? Like Gryffana cloud only becomes... Like it's only at a certain scale, it becomes, you know, important, right? Or like at a very early scale or a very late scale where, you know, managing a self-hosted cluster is sort of getting too much over it. At that point, you can rely on a cloud. But in the mid to mid tier, or go in superskid or like, you know, like as Ashok says in enterprise scenarios, people have their own Gryffana setups already. So there has to be a sort of a good way to integrate this pipeline with the Gryffana dashboard that people already have. As you currently said, we don't want to see the data in two, three different dashboards, right? The same would happen if we have our own Gryffana dashboard and Gryffana cloud dashboard just for the synthetic side of the thing. So some integration would definitely be super awesome and nice, but yeah, let's see how that works. So if folks are fine with keeping the synthetics data in cloud, then, you know, you can install the app on your local and configure it. Give it data sources, give it credentials to connect to cloud. So then you don't have to go to Gryffana instances to see this data. Like it will all be in single instance, but again, the data is really good. With some latency, of course, like if you're talking a pre-hop thing, then you have to pay with some latency. But I think like from a historical point of view, that would still be relevant enough. Maybe not a PZOP one point of view, but we can still analyze historical data from certain locations if too many customer complaints are happening from a certain region, right? We can figure that part at this point. Yeah. Anyone else here does this with any other tool seats in there? Or we can start having that panter station at discussion, I guess. We still have online time, still at least the administrative time right now according to the schedule. Okay, 12.15. So two minutes till the live stream ends. So you can still ask questions or we can take all the questions to the scheduled panter station that we always do, where we go off the record and we can talk about everything under the sun. So till that time, like are there people here who are already using other sort of tool seats to synthetic monitoring? Telegraph, Telegraph has a HTTP and a TCP plugin, I guess, with which you can do synthetic monitoring. We have tried to talk a lot of times. So I think a lot of the self-hosted setups would basically be deploying your Pintest monitor in across multiple locations and then get the data to stream to your central monitoring location or the meta monitoring location, something like that. Right? Yeah. I'd like to add something. Okay, yeah. So I've started consulting just a month back. So the company I consult right now, they're using Pingdom for basically Pintest and all of that. And recently they kind of faced an issue where the tests are basically just timing out, not even able to reach and all of that. So we're just exploring what new options are available or partnering them. And I think DataDog has been offering of synthetic monitoring because they've been using that. So what do you guys think about like DataDog synthetic monitoring and do you have any views on that? Because we have not been using Gifana Cloud so it would be difficult to suggest using a completely different product for it since they've been using it. So it seems like a good option, more or less. And also another question of mine was like if a product is region based, like for example, just in India, like how, like you won't have so many probes to check. Like mostly data centers are either in Mumbai or somewhere else. It's just like one or two probes that you would get in a specific country or something like that. So if you wanted to do more of a regional check, like if customers from Delhi can connect or customers from Chennai can connect, how would you do solve that kind of problem? But like something like DataDog or maybe we have to do something in-house.  So not really sure. You can leverage a couple of mid tier sort of bare metal companies which have certain other data centers but other than that, not really anyone else would pitch in on this. So I would say using bare metal offerings and then running private probes on them would be a way to go. And if you really want to check from you this point of view, I would say send a nuke to every employee of your company and then let them in. Yeah, I mean, yeah. If you do have a data center, you know, ask them to run a Raspberry Pi and... Yeah, that seems like a good option. I mean, I'm going to the extreme but yeah. Give your customers discount to run a probe from their end. Oh yeah. Just built it into the app itself. This is what I think a lot of telecom companies do, right? If they're putting up a tower on top of your building or something, you get a flat discount or some payment out of that. So this is already sort of a business practice in certain domains. So whatever is that, not sure. Yeah, I was in project before. So we used to use data docs for all of that and it didn't use to because we didn't have a website and stuff. So we didn't use to have that many of problems. So yeah, this is relatively new. But data docs also won't do like Indian region-based splits, right? It will still do maybe Delhi, Chennai, you know, Mumbai, Bangalore. There's no data center in Bangalore. So you're limited to Delhi and Mumbai and maybe Chennai. There is a couple of places. Hyderabad has a couple of places, I think. But not sure, you're limited by where data doc has a center, right? They don't have much fine green if I believe you only have India green. They don't have state green, right? Right, right. Also, like I was looking at Cloudflare workers, but they don't allow, you know, Golan. So I can't run. Otherwise, I would have, you know, deployed it on Cloudflare workers and suggested that as a solution. But yeah. Yeah, that's a good option. Maybe you can write something on your own in a language that they support and then deploy. Just write a shell script. Yeah. When back to old Zabix and, you know, those days, all probes were shell scripts. There was no fancy language. You used to use grep and said an opt to filter out the data point and send it. Right, right. Naju's anyway. If you point of time, every new software was a shell script or an extension.


Hey guys welcome back to my YouTube channel this is Daniel Rosel here always trying to find new places to eat and drink in Jerusalem where I am bringing this video to you from is the Scottish guest house overlooking the old city it is a it's affiliated with the Scottish church and those who are not no Jerusalem probably have seen the big Scottish flag the flag the cross of Saint Andrews on the roof here there is a church here but they also have accommodation um traditionally typically used by pilgrims but anyone can stay here believe it or not my wife and I actually got married not in the church but on the grounds of this place we had a beautiful wedding and a really really nice cooperation from the team here um so a restaurant has opened up recently um on the grounds here I don't know if it's affiliated to the church the guest house it's called Saint Urban and we just had dinner there they do some wine they we had a cheese plate I always mention my videos in Jerusalem a lot of people do keep kosher it's not a kosher venue but we had some wine they had Israeli wines foreign wines and the prices were really really actually surprising reasonable now of course you don't go out to dinner just for food you go out to dinner for ambiance and this is in my opinion one of the most beautiful views of Jerusalem in the city I've done a couple of videos before about Givata Tarnach Bible Hill that's located literally just right there look at the view behind me this is beautiful this is the walls of the old city of Jerusalem which are always illuminated illuminated at night time you can see Brichata Sultan which is a natural pool of historic significance that is now serves as an entertainment venue and the Jerusalem municipality is currently putting on a sort of a team building event for some of its workers and you can see the road leading up to the old city adorned with these lovely lights and of course palm trees so this is beautiful it's a great place to stay and now you can also enjoy some good wine and some good food in St. Urban's downstairs


What's up everybody Jason here for Jasper's case breaks calm 2020 black football six box half case break picker teams number 12 just sold out We had a big 17 team R&B Here are the customer names and the teams part of right here, and then here are the customer names Hey Jacob that is not sold out yet. We're trying to sell it out right now So we have 10 mixer spots hiding in this little small filler pack break. We're giving away 10 spots there So once we sell that pack breakout that I just dropped the link for then we can break open the mixer There's a customer names And here are the six boxes that are remaining from the first half earlier today And we got a little Christian McCaffrey to start us off as part of the R&B spot zero It's going to Christopher Here's a teddy bridge water that is not numbered so everybody have a shot at this at the end of the break We'll randomize all the unnumbered base in one lot Antonio Gandy golden little three-color patch 24 to 25 That is for the Washington football team 24 It's gonna go to spot four and Christopher Jonathan Taylor 15 out of 25 Colts spot five. It's going to Kurt and Van Jefferson little patch auto 79 out of 99 Rams R&B Not anyone a crisp parent our next box Little Jerry golf 27 out of 99 It's about seven going to Debra Layer of its jail or the R&B randomizer La Michael P. Ryan for the Jets 30 out of 125 David Chan And we have Tonya Gibson 36 out of 99 36 Going to Christopher. Hey, what's up Pat? How's it going Mac? How's it going? And we got Damian Arnett to 25 out of one Radis going to Michael some P. Ryan 53 out of 75 Torellus 53 When Adam There's that the Michael P. Ryan again David with that one Darrington Evans nine out of 50 Tennessee Titans nine one Chris CJ Henderson 31 out of 189 Jacksonville Jaguars one When a Christopher Darrington Evans little Jersey auto 19 out of 99 another one for spot 9 and Chris All right, how far through guys another three boxes Well one of the points being revealed there DJ Dallas seven out of 25 Cowboys going to Dallas army started Alex. That's what I want to say chase young Michael Pittman, Jr To 75 relic for the Colts R&B five Gonna Kurt 400 points There's a lot Michael P. Ryan 45 out of 50 It's the IG cruise favorite player right there 45 out of 50 and a David Chan straight up Two more guys two more He used to get the old man to give him some more carries is what he needs the old man Gore 91 out of 99 Houston Texans going to Aaron Gardner Minchu unnumbered Everybody I shot at that again little Brian Edwards 20 or 38 out of 50 38 spot eights or actually Michael Robison has the ravers KJ Hamler autograph and that's two out of five KJ Hamler Very nice two Spot two that's going to Sean and van Jefferson nice two-color patch 14 Out of 50 spot four going to Christopher P Two-color patch What's up, what's up going man? What up? What up? I go Chris And the last one here folks. Good luck Sam Darnold The judge going to David green bit Packers Alex Jake from Bills 57 Seven going to Debra Tommy Stevens 34 out of 199 Four Saints Christopher And Joshua Kelly 35 out of 99 and spot five chart or chart Chargers going to Daniel There you go guys. That was the break. So these were the unnumbered cards right here One two three four for the random number block randomizer and number one has everybody has a shot at this right here So we're randomize it by team name Um, remember that so teams So whenever team to the top gets it and if it's a random number block team Then we will also randomize this and see who wins that Sorry, Pat. I know man. There was I was very surprised that there wasn't like no Justin Herbert in this either No Herbert No crazy Joe Burrell And what's his name took off today to Deondre Swift, didn't he? So this is the random number block randomizer for customers for the base And then everybody have a shot at this. We're just randomize by team names Yeah All right, let's roll it and we got a one and a five six times one two three four five six Oh So rick s you're gonna get all the unnumbered base cards, which still is about like four of them And then six times here for the 400 points one two three four five six My eagles at the top There you go, but that was also part of the random number block. So How about we do this let's get a new randomizer And we'll randomize the customer names again In the random number block randomizer and number one on this one is going to get the 400 points So everybody gets a piece of that so six times one two three four five six Debra at the top there you go And there you go guys, this is Pikachu number 12 a black football on jazby's case breaks.com