project proposal

backmatter/devopsAIPromptLog.tex

@@ -100,3 +100,24 @@ Codex copied additions into the student's supplied course repository location.\\
 compiler work was not present in the inspected repository. Full compilation,
 combined report review, repository publication, and Canvas submission are not
 claimed by this record.
+
+
+\subsection{Record 6 --- Inviscid Project Proposal}
+\textbf{Date:} October 6, 2026.\\
+\textbf{Tool:} OpenAI Codex.\\
+\textbf{Task:} Brainstorm Inviscid, refine the metrics-tool comparison and
+research question, and write the approved proposal into the course repository.\\
+\textbf{Inputs:} The assignment outline, instructor clarification, Victor's
+project preferences and corrections, current repository sources, and official
+Prometheus and VictoriaMetrics documentation.\\
+\textbf{Output used:} Project description, sample task, tentative tool choices,
+research question, planned comparison, independent SWOT assessments, and
+supporting document updates.\\
+\textbf{Human decisions and corrections:} Victor approved the monitoring-service
+concept, selected VictoriaMetrics instead of InfluxDB, approved the research
+question, and requested independent SWOT assessments and candidate tools
+explicitly marked undecided.\\
+\textbf{Review boundary:} The monitoring prototype, tool comparison, and
+pipeline remain proposed work. No performance results or completed monitoring
+features are claimed. The combined report still requires final author review
+and compilation before submission.

chapters/devopsProjectProposal.tex

@@ -1,19 +1,111 @@
 \chapter{Project Proposal}
 \ChapterLabel{ProjectProposal}
-\index{GitHub Actions}\index{Jenkins}
+\index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}
 
-\section{Proposed Tool: GitHub Actions}
-We propose researching GitHub Actions and comparing it with Jenkins, which
-will be introduced in class. GitHub Actions interests us because our group
-already uses GitHub to maintain source code and documentation. We want to
-understand how repository workflows can automate the build, testing, and
-deployment of our Dockerized website to AWS.
+\section{Inviscid: Simple Monitoring for Small Web Services}
+Inviscid is a proposed customer-facing startup that helps small businesses
+monitor the health and performance of their web applications. Customers would
+use a dashboard to view availability, response times, request volume, and
+error rates. The service would pair these measurements with plain-language
+status summaries, such as ``Your website is responding slowly,'' to help
+customers recognize problems without requiring extensive monitoring expertise.
 
-Our comparison will consider setup effort, workflow configuration, and
-visibility into build and deployment results. A future demonstration could
-provide a manually triggered workflow that builds and deploys the application.
-For this proposal, no installation or implementation of the comparison tool
-is claimed. The current proof of concept is the manually deployed EC2 website.
+The semester prototype will focus on one demonstration customer application,
+building on our existing Node.js website. The broader startup concept is a
+future direction; customer account management and support for multiple
+customers are outside the initial prototype. Our current proof of concept is
+the Dockerized Color Buttons website deployed on AWS, documented in
+\ChapterRef{CloudDockerDeployment}. Monitoring and deployment automation are
+proposed work rather than completed features.
 
-% Draft selection based on the earlier discussion: both authors should confirm
-% GitHub Actions versus Jenkins before submitting this chapter.
+\subsection{Sample Customer Task}
+A customer opens the Inviscid dashboard to check their website's health.
+During a controlled demonstration, we will generate normal traffic and then
+introduce slow responses or failed requests in the sample application. The
+dashboard should display the resulting changes in response times and error
+rates, accompanied by a short status summary explaining the problem.
+
+\section{Proposed Development and Operations Tools}
+GitHub will provide source control and collaboration, and AWS will provide
+the deployment environment. Table~\ref{Table:InviscidTools} lists the planned
+stack. Entries marked undecided are candidates, not commitments; the team
+may revise them as implementation requirements become clearer.
+
+\begin{tabularx}{\linewidth}{L{3.2cm}Y}
+\caption{Tentative Inviscid Tool Selection\label{Table:InviscidTools}}\\
+\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
+\endfirsthead
+\toprule \textbf{Purpose} & \textbf{Tool and status}\\ \midrule
+\endhead \bottomrule \endlastfoot
+Source control & GitHub; selected.\\
+Application & Node.js and Express; proposed, building on the existing website.\\
+Container packaging & Docker; selected.\\
+Deployment & AWS EC2; selected for the prototype.\\
+Metrics backend & Prometheus and single-node VictoriaMetrics; selected for comparison, final backend undecided.\\
+Dashboard & Grafana or a simple custom dashboard; undecided.\\
+Automated testing & Node.js's built-in test runner and a traffic-generation script; undecided.\\
+Deployment automation & GitHub Actions for a manually triggered build, test, and deployment workflow; undecided.\\
+Customer/settings database & Amazon DynamoDB, if persistent customer configuration is needed; undecided. Metrics will be stored in the selected metrics backend.\\
+Security checks & GitHub Dependabot and automated dependency checks; undecided.\\
+\end{tabularx}
+
+Our longer-term goal is a deployment pipeline that can be initiated with one
+button press. The proposal does not claim that this pipeline is implemented.
+
+\section{Research Question and Planned Comparison}
+\begin{quote}
+How do Prometheus and VictoriaMetrics compare as metrics backends for
+Inviscid's prototype in terms of configuration effort, dashboard integration,
+query response time, and CPU, memory, and storage usage?
+\end{quote}
+
+We selected these tools because both can collect and query application metrics,
+and VictoriaMetrics can scrape Prometheus-compatible endpoints. This allows
+us to reuse the instrumented application while investigating different
+backend implementations. Prometheus includes metric scraping, PromQL queries,
+and alert-rule evaluation. VictoriaMetrics provides metric collection and
+storage with MetricsQL queries; alert-rule evaluation uses a separate component
+such as \texttt{vmalert}. Supported configuration options and query behavior
+will be checked rather than assumed identical.
+
+We plan to compare Prometheus with single-node VictoriaMetrics using the same
+application, metrics, traffic workload, collection interval, retention period,
+and equivalent AWS resources. Configuration effort will be documented through
+setup steps and difficulties; dashboard integration through the work required
+to display equivalent measurements. Repeated equivalent queries and controlled
+traffic will support measurements of query response time and CPU, memory,
+and storage usage. Results will apply to the tested prototype and workload;
+we will not assume that either tool is faster or more resource-efficient.
+
+\section{Preliminary SWOT Analysis}
+Table~\ref{Table:InviscidSWOT} evaluates each tool independently in the context
+of Inviscid. Strengths and weaknesses describe tool characteristics;
+opportunities and threats describe possible circumstances affecting its use.
+These are preliminary assessments, not measured experimental results.
+
+\begingroup
+\small
+\begin{tabularx}{\linewidth}{L{2.0cm}YY}
+\caption{Preliminary SWOT for Inviscid's Metrics Backends\label{Table:InviscidSWOT}}\\
+\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
+\endfirsthead
+\multicolumn{3}{l}{\small\itshape Preliminary SWOT (continued)}\\
+\toprule \textbf{Category} & \textbf{Prometheus} & \textbf{VictoriaMetrics}\\ \midrule
+\endhead \bottomrule \endlastfoot
+Strengths & Established open-source ecosystem; built-in metric collection and alert-rule evaluation; expressive PromQL query language. & Simple single-node deployment; built-in metric collection and storage; flexible MetricsQL query language and multiple supported ingestion formats.\\
+Weaknesses & Local storage is neither clustered nor replicated; operating at larger scales requires additional architecture. & Alert-rule evaluation requires a separate component; the single-node deployment depends on one server for availability.\\
+Opportunities & Inviscid could extend monitoring to containers and infrastructure through its existing exporter ecosystem. & Inviscid could accept metrics from different customer environments through its supported ingestion formats.\\
+Threats & Rapid growth in customer metrics could exceed available resources and increase operating costs. & Customers requiring uninterrupted monitoring could necessitate a cluster deployment, increasing infrastructure and maintenance costs.\\
+\end{tabularx}
+\endgroup
+
+\section{Technical Sources}
+The technical characteristics above are based on the following official
+documentation, consulted October 6, 2026. Opportunities and threats are the
+team's project-specific assessments. Specific tool versions will be recorded
+when the comparison is implemented.
+\begin{itemize}
+\item \href{https://prometheus.io/docs/introduction/overview/}{Prometheus overview}: collection, queries, exporters, and alerting components.
+\item \href{https://prometheus.io/docs/prometheus/latest/storage/}{Prometheus storage}: local storage limitations and remote storage interfaces.
+\item \href{https://docs.victoriametrics.com/victoriametrics/}{VictoriaMetrics documentation}: single-node deployment, scraping, ingestion, MetricsQL, and supporting components.
+\end{itemize}

devopsAssignment.tex

@@ -40,14 +40,14 @@
 % Replace these values for each assignment.
 \newcommand{\AssignmentTitle}{Cloud Docker Deployment, LaTeX Docker, and Project Proposal}
 \newcommand{\AssignmentNumber}{3}
-\newcommand{\DocumentVersion}{3.1}
+\newcommand{\DocumentVersion}{3.2}
 \newcommand{\DocumentStatus}{Group Report Draft}
 \newcommand{\CourseNumber}{SSW 590}
 \newcommand{\CourseName}{DevOps}
 \newcommand{\Author}{Payton Bates and Victor Del Rio Foces}
 \newcommand{\Instructor}{Darian Muresan, Ph.D.}
 \newcommand{\Organization}{Stevens Institute of Technology}
-\newcommand{\DocumentDate}{October 5, 2026}
+\newcommand{\DocumentDate}{October 6, 2026}
 \newcommand{\DueDate}{October 6, 2026 by 11:59pm}
 \newcommand{\VERSION}{Version \DocumentVersion}
 

frontmatter/abstract.tex

@@ -7,4 +7,5 @@ distinguishes machines in service from those still planned.
 Assignment 3 adds the class-based Color Buttons application deployed in Docker
 on Amazon EC2, with public browser and terminal verification evidence;
 a Docker container that compiles \LaTeX\ documents as Overleaf does;
-and a proposal to compare GitHub Actions with Jenkins.
+and the Inviscid monitoring-service proposal, including a planned comparison
+of Prometheus and VictoriaMetrics.

frontmatter/devopsDocumentHistory.tex

@@ -11,6 +11,7 @@ link each entry to the changed chapter, table, figure, or controlled artifact.
 \multicolumn{4}{l}{\small\itshape Document Update History (continued)}\\
 \toprule \textbf{Date / Version} & \textbf{Author Initials} & \textbf{Change} & \textbf{Changed At}\\ \midrule
 \endhead \bottomrule \endlastfoot
+October 6, 2026 / 3.2 & VDRF & Replaced the preliminary tool proposal with Inviscid, its sample customer task, tentative stack, research question, and independent SWOT assessments of Prometheus and VictoriaMetrics. Updated the abstract and AI log. & \ChapterRef{ProjectProposal}, \ChapterRef{AIPromptLog}\\
 October 5, 2026 / 3.1 & PCB & Added the LaTeX Docker chapter for compiling a sample document with its sources, build and run commands, and test evidence. Updated the document title, keywords, glossary,  abstract, introduction, and hosts. & \ChapterRef{LatexDocker}, \ChapterRef{Hosts}, \ChapterRef{Introduction}, \ChapterRef{CloudDockerDeployment}\\
 October 5, 2026 / 3.0 & VDRF & Added AWS Docker deployment, class-based website sources, execution evidence, and a draft tool-comparison proposal. Updated Assignment 3 metadata and AI log. & \ChapterRef{CloudDockerDeployment}, \ChapterRef{ProjectProposal}, \ChapterRef{AIPromptLog}\\
 September 27, 2026 / 2.1 & VDRF & Added Victor's Q1--Q40 execution screenshots and result interpretation; distinguished the two environments and command variants. & \ChapterRef{LinuxCommands}, \ChapterRef{AIPromptLog}\\