project proposal
This commit is contained in:
1 parent
c9d06e0b5a
commit
13bce6144c
5 files changed
+132
-17
No files matched your search
@@ -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,
|
compiler work was not present in the inspected repository. Full compilation,
|
||||||
combined report review, repository publication, and Canvas submission are not
|
combined report review, repository publication, and Canvas submission are not
|
||||||
claimed by this record.
|
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.
|
||||||
@@ -1,19 +1,111 @@
|
|||||||
\chapter{Project Proposal}
|
\chapter{Project Proposal}
|
||||||
\ChapterLabel{ProjectProposal}
|
\ChapterLabel{ProjectProposal}
|
||||||
\index{GitHub Actions}\index{Jenkins}
|
\index{Inviscid}\index{Prometheus}\index{VictoriaMetrics}\index{observability}
|
||||||
|
|
||||||
\section{Proposed Tool: GitHub Actions}
|
\section{Inviscid: Simple Monitoring for Small Web Services}
|
||||||
We propose researching GitHub Actions and comparing it with Jenkins, which
|
Inviscid is a proposed customer-facing startup that helps small businesses
|
||||||
will be introduced in class. GitHub Actions interests us because our group
|
monitor the health and performance of their web applications. Customers would
|
||||||
already uses GitHub to maintain source code and documentation. We want to
|
use a dashboard to view availability, response times, request volume, and
|
||||||
understand how repository workflows can automate the build, testing, and
|
error rates. The service would pair these measurements with plain-language
|
||||||
deployment of our Dockerized website to AWS.
|
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
|
The semester prototype will focus on one demonstration customer application,
|
||||||
visibility into build and deployment results. A future demonstration could
|
building on our existing Node.js website. The broader startup concept is a
|
||||||
provide a manually triggered workflow that builds and deploys the application.
|
future direction; customer account management and support for multiple
|
||||||
For this proposal, no installation or implementation of the comparison tool
|
customers are outside the initial prototype. Our current proof of concept is
|
||||||
is claimed. The current proof of concept is the manually deployed EC2 website.
|
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
|
\subsection{Sample Customer Task}
|
||||||
% GitHub Actions versus Jenkins before submitting this chapter.
|
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}
|
||||||
@@ -40,14 +40,14 @@
|
|||||||
% Replace these values for each assignment.
|
% Replace these values for each assignment.
|
||||||
\newcommand{\AssignmentTitle}{Cloud Docker Deployment, LaTeX Docker, and Project Proposal}
|
\newcommand{\AssignmentTitle}{Cloud Docker Deployment, LaTeX Docker, and Project Proposal}
|
||||||
\newcommand{\AssignmentNumber}{3}
|
\newcommand{\AssignmentNumber}{3}
|
||||||
\newcommand{\DocumentVersion}{3.1}
|
\newcommand{\DocumentVersion}{3.2}
|
||||||
\newcommand{\DocumentStatus}{Group Report Draft}
|
\newcommand{\DocumentStatus}{Group Report Draft}
|
||||||
\newcommand{\CourseNumber}{SSW 590}
|
\newcommand{\CourseNumber}{SSW 590}
|
||||||
\newcommand{\CourseName}{DevOps}
|
\newcommand{\CourseName}{DevOps}
|
||||||
\newcommand{\Author}{Payton Bates and Victor Del Rio Foces}
|
\newcommand{\Author}{Payton Bates and Victor Del Rio Foces}
|
||||||
\newcommand{\Instructor}{Darian Muresan, Ph.D.}
|
\newcommand{\Instructor}{Darian Muresan, Ph.D.}
|
||||||
\newcommand{\Organization}{Stevens Institute of Technology}
|
\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{\DueDate}{October 6, 2026 by 11:59pm}
|
||||||
\newcommand{\VERSION}{Version \DocumentVersion}
|
\newcommand{\VERSION}{Version \DocumentVersion}
|
||||||
|
|
||||||
|
|||||||
@@ -7,4 +7,5 @@ distinguishes machines in service from those still planned.
|
|||||||
Assignment 3 adds the class-based Color Buttons application deployed in Docker
|
Assignment 3 adds the class-based Color Buttons application deployed in Docker
|
||||||
on Amazon EC2, with public browser and terminal verification evidence;
|
on Amazon EC2, with public browser and terminal verification evidence;
|
||||||
a Docker container that compiles \LaTeX\ documents as Overleaf does;
|
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.
|
||||||
@@ -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)}\\
|
\multicolumn{4}{l}{\small\itshape Document Update History (continued)}\\
|
||||||
\toprule \textbf{Date / Version} & \textbf{Author Initials} & \textbf{Change} & \textbf{Changed At}\\ \midrule
|
\toprule \textbf{Date / Version} & \textbf{Author Initials} & \textbf{Change} & \textbf{Changed At}\\ \midrule
|
||||||
\endhead \bottomrule \endlastfoot
|
\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.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}\\
|
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}\\
|
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}\\
|
||||||
|
|||||||
Reference in new issue
Block a user